0% found this document useful (0 votes)
48 views

Software Development Sheet

The document discusses key terms related to software development quality like correctness, integrity, reusability, and scalability. It also discusses quality expectations for different types of software like air traffic control software and a personal diary mobile app. The document then covers various exercises related to software development processes, principles, and best practices.

Uploaded by

malkmoh781.mm
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
48 views

Software Development Sheet

The document discusses key terms related to software development quality like correctness, integrity, reusability, and scalability. It also discusses quality expectations for different types of software like air traffic control software and a personal diary mobile app. The document then covers various exercises related to software development processes, principles, and best practices.

Uploaded by

malkmoh781.mm
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 23

Software Development Sheet

Name: Abdo Mohamad Sayed Mohamad ‫عبدالرحمن محمد سيد محمد‬


Department: CS
Section: 1
Chapter 1
Exercise 1.2: Define the following terms:
SW Correctness & Integrity: Correctness means that The software we are
developing should fulfil all of the customer’s requirements and integrity means
that the program may have a side effect, in the same way as medications do, in
that it may interfere with the operation of another application. A good piece of
software, on the other hand, should not have any negative consequences.

SW Reusability & Scalability: Reusability means that there should be no flaws in


the software product. Not only that, but it must not fail during execution and
scalability means that It should be simple to update it to handle greater work
(or for more number of users).

Exercise 1.4: In your opinion, what are the quality expectations for "Air Traffic
Control Software" and "Personal Diary Mobile App" might be?

I think that Quality expectations for software can vary based on the specific
requirements, user needs, and industry standards, for "Air Traffic Control
Software" it should be reliable, stable, efficient, secure, scalable, and have
integrity. And for "Personal Diary Mobile App" it should have ease of use,
privacy and security, sync and backup, customization, search and organization,
offline access and capability.

Exercise 1.7: What we mean by, "The developer should tell in failure"?

It means that means that when something goes wrong in a computer program,
the developer should make sure the program explains the problem in a clear
and understandable way to the person using the software. This could be
through messages that pop up on the screen, so the user knows what happened
and, if possible, what they can do to fix it. It's like having the computer speak up
and say, "Hey, something didn't work, and here's why." This helps users and
developers figure out and fix issues more easily.
Chapter 2
Exercise 2.2: Describe the process you have for a programming task, from
requirements to delivery?

It’s called SDLC and it has:


1. Understand the requirements
2. Plan your approach
3. Write the code
4. Test the code
5. Document your code (not necessary)
6. Final testing
7. Make any necessary adjustments
8. Prepare for delivery
9. Deliver

Exercise 2.4: What we mean by the “scope” of a project?

The "scope of a project" refers to everything that the project is supposed to


accomplish. It includes all the tasks, goals, features, and work that needs to be
done to successfully complete the project. The scope outlines the boundaries
and details of what is and isn't part of the project.

Exercise 2.6: Which part of the system life cycle do you think is the most
innovative and challenging?

The "Development Phase" is often considered the most innovative and


challenging. This is when the actual system or software is created, requiring
creative problem-solving and the introduction of new ideas to meet project
requirements.
Exercise 2.9: Explain how the principles underlying agile methods lead to the
accelerated development and deployment of software?

Agile methods speed up software development and deployment by focusing on


these key principles like Flexibility, Iterative Progress, Customer Collaboration,
Team Empowerment, Continuous Improvement and Early and Regular Delivery.

Exercise 2.12: Briefly, describe is Pair Programming Good or Bad?

Whether pair programming is considered good or bad depends on the team, the
nature of the project, and individual preferences. Some teams find it highly
beneficial for improving code quality and collaboration, while others may find it
less efficient or suitable for certain tasks. It often comes down to the specific
context and the team's dynamics.

Exercise 2.14: Giving reasons for your answer based on the type of system being
developed, suggest the most appropriate software process model that might be
used as a basis for managing the development of the following systems:
• A system to control anti-lock braking in a car.
• A virtual reality system to support software maintenance.
• A university accounting system that replaces an existing system.
• An interactive travel planning system that helps users plan journeys with the
lowest environmental impact.

System to Control Anti-Lock Braking in a Car:


 Recommended Process Model: Incremental Model or V-Model
 Reasoning:
 Safety is a critical concern in automotive systems. Incremental or V-
Model allows for iterative development and testing, ensuring that
safety-critical features are validated at each stage. This approach
aligns well with the need for thorough testing in automotive
software development.
Virtual Reality System to Support Software Maintenance:
 Recommended Process Model: Agile Model
 Reasoning:
 Virtual reality systems often involve rapid prototyping and
continuous feedback. Agile is well-suited for such dynamic and
evolving projects. It accommodates changes easily and encourages
collaboration, which is essential for developing effective virtual
reality tools for software maintenance.
University Accounting System Replacing an Existing System:
 Recommended Process Model: Waterfall Model or Iterative Model
 Reasoning:
 Given the nature of replacing an existing system in a university
environment, a well-defined and structured approach is crucial. The
Waterfall Model provides a linear and systematic progression,
while the Iterative Model allows for refinement based on user
feedback. The choice depends on the level of flexibility and
feedback required during development.
Interactive Travel Planning System for Low Environmental Impact:
 Recommended Process Model: Spiral Model or Agile Model
 Reasoning:
 Environmental impact considerations may involve evolving
requirements and continuous feedback from users. The Spiral
Model allows for risk assessment and adjustments at each iteration,
making it suitable for projects with changing objectives. Agile, with
its iterative and adaptive nature, is also well-suited for responding
to evolving user needs in a dynamic domain like travel planning.
Exercise 2.24: Give two benefits that arise from test first development.

Improved Code Quality and Faster Feedback and Iterative Development.

Exercise 2.29: Read Then Answer?


Key stakeholders with product owner, team leader and his team in a meeting. As
the product owner began to share the project’s vision, a stakeholder asked when
they would receive the full project management plan. How does agile master
respond to that request?
1. Promise to submit as soon as possible.
2. Tell the stakeholder that it will be ready after collecting all requirements.
3. Talk with the stakeholder about agile mindset.
4. Tell stakeholders that no documentation is needed in agile projects.

Answer: 3. Talk with the stakeholder about agile mindset.

Exercise 2.30: Read Then Answer?


The project team receives many phone calls and emails sent by the customer for
changes, and this situation may delay the team to finish the work required in the
recent sprint. The team raised the issue to the scrum master and the product
owner.
What should the product owner do next?
1. Ask the customer to submit an official change request.
2. Ask the team to implement the changes.
3. Face to face meeting with all concerned parties to explore the issue.
4. Ask the customer to stop emails.

Answer: 1. Ask the customer to submit an official change request.


Chapter 3
Exercise 3.1:
Variables don’t need meaningful context.

Exercise 3.2:
Exercise 3.3:

Conditional is too long

Exercise 3.4:

It might cause a side-effect.


Line 4 is checking if the name given is there and if it’s, then the function
“checkPassword” will return false; meaning that the password doesn’t match the
correct one, when there is no user with that name.

Exercise 3.5:

* Pronounceable names.
* Breaking indentations.
* Searchable names.
* have no side effect.
Exercise 3.6:

1 - Indentation: The code is indented consistently, making it clear and easy to


follow the structure of the code blocks.
Spacing: Adequate spacing is used around operators and keywords, enhancing
readability.
Brace Placement: The placement of braces follows a common style, where the
opening brace is on the same line as the control statement. This is a matter of
personal or team preference, but consistency is key.
Descriptive Variable Names: The variable names (j, k, i, m) are short but
descriptive enough in the context of the code snippet.

2-

3 - It would result in a syntax error, and the compiler would likely fail to build
the code successfully. The corrected version addresses this syntax error by using
the correct comparison operators
4 - The code appears to be related to searching or counting elements in an array
based on certain conditions. Specifically, it may be part of a program that
processes an array (v) and counts the occurrences of elements meeting a
particular criterion, which is defined by the conditions in the if statement within
the loop.
Exercise 3.7:

 Legal comments like:

 TODO comments like:

Exercise 3.8:
Chapter 4
Exercise 4.6: The DRY principle is closely related to the concept of "Single
Responsibility Principle" (SRP) and is one of the guiding principles of good
software design and architecture. By adhering to DRY, developers aim to write
clean, maintainable code that minimizes the risk of errors and facilitates future
enhancements.

Exercise 4.7: The KISS principle, which stands for "Keep It Simple, Stupid" or
"Keep It Short and Simple," is a design philosophy that advocates simplicity and
clarity in system and software design. The core idea is to avoid unnecessary
complexity and to favor simplicity whenever possible. The principle suggests that
simpler designs are often easier to understand, maintain, and troubleshoot. It has
some hey aspects like simplicity, clarity, minimalism and more.
Exercise 4.11: The code provided has a design issue related to the violation of the
Liskov Substitution Principle (LSP), the Liskov Substitution Principle states that
objects of a superclass should be replaceable with objects of a subclass without
affecting the correctness of the program.
In the given code:
The “run” method in the Feline class is declared as public, but in the Tiger class, it
is overridden with a private access modifier. According to LSP, the visibility of
overridden methods should not be more restrictive than the visibility of the
method in the superclass.
The private method eat in the Feline class is not accessible in the Tiger class. This
does not violate the LSP directly, but it limits the ability to extend or override the
behavior of the eat method in subclasses.
To adhere to the Liskov Substitution Principle and improve the design:
The overridden methods in the subclass (Tiger) should not reduce the visibility of
the methods defined in the superclass (Feline). If the superclass has a public
method, the overriding method in the subclass should be at least public.
Consider making methods like eat in the Feline class with at least protected
access if you want to allow subclasses like Tiger to have access to and potentially
override them.
Exercise 4.12:
 Scenario 1 violates SRP (Single Responsibility Principle).
 Scenario 2 violates LSP (Leskov Substitution Principle).
 Scenario 3 violates ISP (Interface Segregation Principle).
Exercise 4.13:
Exercise 4.14:
The SOLID principle that can improve the code segment is the Single
Responsibility Principle (SRP). The Human class is currently responsible for both
storing personal information (name, age) and generating a full address string,
violating the SRP. Ideally, a class should have only one reason to change.
Refactored version of the code:
Chapter 5
Exercise 5.3:
Exercise 5.4: Using the Singleton pattern in this scenario helps in managing the
shared resource (the printer) efficiently, ensuring that there's only one instance of
the printer that handles print jobs for all the employees.

Exercise 5.5: Program to Interface is a design principle that encourages


programming against interfaces rather than concrete implementations. It
depends on abstractions (interfaces or abstract classes) rather than specific
implementations, by programming to an interface, you create code that is more
adaptable to change. If you decide to change or extend a specific implementation,
you can do so without affecting the code that uses the interface. This makes the
system more modular and less coupled to specific implementations.
Example:
Exercise 5.7: In a multi-threaded environment, the traditional implementation of
the Singleton pattern may face a problem known as the "Double-Checked
Locking" problem. This issue arises when multiple threads are involved and can
lead to the creation of multiple instances of the Singleton, which contradicts the
purpose of having a single, globally accessible instance.
The problem occurs when two or more threads simultaneously enter the
conditional check where the Singleton instance is created. If the instance does not
exist, both threads may proceed to create an instance, resulting in the creation of
multiple instances. This can happen because the check for the existence of the
instance and the creation of the instance are not atomic operations.
Example:
Chapter 6
Exercise 6.1: Based on the description provided, it seems like you need a flexible
and extensible message generator for creating mission plans for a wireless sensor
system. So composite design pattern will be perfect for this scenario.

To address the issue of having different interfaces for XML and JSON formats, you
can use the Adapter Pattern. The Adapter Pattern allows incompatible interfaces
to work together. In this case, you can create an adapter that converts the XML
format to the JSON format so that both types of clients can use the product
seamlessly.
Exercise 6.3: Façade design pattern.

Exercise 6.4: To integrate the special character, the Adapter Pattern allows
objects with incompatible interfaces to work together.
Chapter 7
Exercise 7.5: To address the scenario described, you can use the Observer
Pattern. The Observer Pattern defines a one-to-many dependency between
objects so that when one object changes state, all its dependents are notified and
updated automatically. In this case, the news agency acts as the subject, and the
subscribers act as observers.
Exercise 7.6: To implement the described scenario, you can use the Observer
Pattern. The Observer Pattern will be well-suited for this scenario.
Exercise 7.7: You can use the Strategy Pattern. The payment options (Credit Card,
Debit Card, and Cash) can be encapsulated as strategies, and Steve can choose
the desired payment option at the bill counter.

You might also like