Assignment

2
: SOFTWARE ENGINEERING
Date: 12.10.2021

Questions:
1. Make your own customer story (being a customer) for software
requirements in Extreme Programming and then break it into a number of
tasks.
2. Discuss the advantages and disadvantages of this approach to the
requirements description.
3. Explain by example, what improvements would be possible in a code as a
result of Refactoring.
4. Explain the idea of Test-First development and highlight possible
problems that may arise as a result of Test-First development.
Solution:
1. Make your own customer story (being a customer) for software
requirements in Extreme Programming and then break it into a
number of tasks.
Answer:
Customer
 The role of the customer in the testing process is to help develop
acceptance tests for the stories that are to be implemented in the
next release of the system.
 The customer who is part of the team writes tests as development
proceeds. All new code is therefore validated to ensure that it is
what the customer needs.
 However, people adopting the customer role have limited time
available and so cannot work full-time with the development team.
 They may feel that providing the requirements was enough of a
contribution and so may be reluctant to get involved in the testing
process.
  As an agile methodology, Extreme programming was designed to
help solve the business challenges and problems that arise during a
software building process.
 The final product will have to be approved by the customer, so
instead of waiting until then, Extreme programming incorporates the
customer into the entire process.
 An on-site customer is critical in all the stages of a software
building process. He/she should be accessed easily not only to help
the software development team but also be a part of the whole
process.

Responsibilities of a Customer in XP
User stories
 Write user stories and ensure the software’s intended functionality is
covered by those stories.
 He/she will be responsible for the provision of the system
requirements and will liaise with the developers, who will help
him/her project the estimate in variables such as time.
Liaise with external stakeholders
  In the entire process, a customer will be required to be the link
between the project funders and the development team.
 He/she will be the link to the clients as well as the end users of the
software.
 The primary concern for the customer is to create and maintain a
budding relationship and also instill confidence in all the parties
involved, more so the developers.
Prioritize
 Be a key determinant in the release planning discussions.
 The customer will need to prioritize the stories and then determine
which one is of more importance and that needs to be completed
first.
 The customer’s role stretches even further as he/she will need to
negotiate on the timing of the release and also select a user.
Set the bar for acceptance testing
 The customer will need to provide the requirements of the system as
per the business that will need to be complied with for the project to
be acceptable.
 This helps the team of developers assess the product to see whether
it’s ready for delivery.
Provide sufficient information to help finish a programming task
 The customer will need to be always in contact with the
development team to provide enough details and help decide which
components are to be postponed in case of an overbooked project
velocity for a given iteration.
 All the above-stated roles of a customer, in an extreme programming
process, point out to the fact that they will always carry a huge
responsibility in ensuring that the project is a success.
 They should be willing and be able to commit lots of time to the
project, from when it’s conceived to the very end.
2. Discuss the advantages and disadvantages of this approach to the
requirements description.
Answer:
Extreme programming (XP) is perhaps the best known and most widely
used of the agile method. The name was coined by Beck because the
approach was developed by pushing recognized good practice
In Extreme programming, requirements are expressed as scenarios which are
implemented directly as a series of tasks. This program involves a number of
practices through Incremental planning, Small releases, Simple design, Test-
first development, Refactoring, Pair programming, Collective ownership,
Sustainable pace, on-site customer.
The use of user stories is not unique to Extreme Programming - user stories
are widely-used in Agile especially Scrum. They are not necessarily written
down on cards - for example, many times, an online Agile Project
Management tool is used to store user stories online.
A user story is considered a “placeholder for conversation” - it is intended
only to be a short and succinct description of the user need and it is expected
that the developer(s) responsible for implementing the user story will further
elaborate the details based on direct communication with the user.
Advantages and Disadvantages of Extreme Programming user
requirements:
Advantages
1. We don’t discuss details of stories (approximately) unless we are
almost certainly going to build the corresponding parts of the system,
so we don’t over-invest in exploring and defining features.
2. The primary advantage of a user story is that it is short and concise and
it expresses the requirement from the perspective of what the user
business need is rather than attempting to tell a developer how to
satisfy that need.
3. Scenarios cope with most of common operation. It is easy to identify
what type of operation that is required in the user’s stories.
4. Customer focus in the scenario card increase the chance that the
software produced will actually meet the needs of the users.
Disadvantages
1. We can’t describe far in advance and in detail the work that we intend
to do. We can describe it far in advance, but not in detail; we can
describe it in detail, but not far in advance.
 2. Using scenarios on a card can bring to a function overlooked or
omission which can be a time-consuming process to complete the
system.
3. Two different scenarios can lead to the same function as it will be
conflicted each other. Crossing out redundant scenarios can be a
cumber some tasks.
4. It relies on direct communications to further elaborate the details of the
requirement and some developers may not be very skilled in doing that.
3. Explain by example, what improvements would be possible in a code as a
result of Refactoring.
Answer:
Refactoring - a change made to the internal structure of software to make it
easier to understand and cheaper to modify without changing its observable
behavior.

Refactoring Makes Your Code Easier to Modify

Simply put, you refactor to improve the design of your software. Any application
under active development is a moving target. As you add new functionality,
cohesion decreases. Abstractions aren't as clean anymore. By refactoring
regularly, you update the code so that it reflects an improved understanding of
the domain. This alignment enables easier modification.
Refactoring Makes Your Code Easier to Understand
Thanks to an improved design, you also make the code easier to understand. It's
a well-known fact that developers read code much more often than they write it.
Thus, it's in your best interest to keep it as understandable as possible, which
greatly increases maintainability. People going over it in the future will thank
you.
Refactoring Is Sharing Knowledge
Finally, refactoring is a way of sharing knowledge. After refactoring a piece of
code, you gain a deeper understanding of what it does, even if you didn't
originally write it. Spreading knowledge is crucial when you're working as a
team.
The Role of Refactoring in Agile Development
 The practice of refactoring is most accepted in agile teams. In an agile
environment, you work in short iterations, continuously releasing small
chunks of functionality that bring value. Fast feedback is paramount for a
quick loop.
 Under these circumstances, it won't be possible to design the whole system
in advance. Many organizations spend a lot of time trying to plan
everything upfront only to realize later on that their assumptions were
wrong.
 Instead, you need to embrace change and build an evolutionary
architecture that you constantly improve. Refactoring is a key part of the
process as you align the code with the architecture, keeping both in sync.
A Sample Refactoring
Let's have a look at a classic: Extract Method. In this refactoring, the goal is to
group a code fragment in a separate method, making the original method smaller
and easier to read. Essentially, this is the recipe:
 Create a new method named after its intention.
 Copy the extracted code from the source into the new method.
 Call the new method from the source, passing the necessary variables.
 Ensure the code works as before.
Let's assume you have this block of code:
fun splitNumbers(source: String): List<Int> { val split = source.split(",") //
convert each string to a number val numbers = split.map { str -> str.toInt() }
return numbers }
I'm going to extract part of it into a new method, bit by bit. In the interest of
space, I'll skip the intermediate steps and show you the result:
fun splitNumbers(source: String): List<Int> { val split = source.split(",") return
convertStringToNumber(split) } fun convertStringToNumber(list: List<String>):
List<Int> { return list.map { str -> str.toInt() } }
If you check the initial code, you'll notice that the method is doing two things at
once, which makes the code more confusing. The comment is a smell that the
responsibilities are not cleanly separated. So, I've extracted that into its own
method, called convertStringToNumber. I'm passing the unprocessed list from
the main method as an argument. Finally, the intermediate variable numbers is
no longer needed. Instead, I'm inlining the auxiliary method call, as the
splitNumbers method's intention is clear now.
Simple, isn't it? I've made the code easier to maintain with little effort. Notice
how I replaced a comment that'll likely go out of sync with a meaningful method
name that describes the block's purpose instead.
4. Explain the idea of Test-First development and highlight possible
problems that may arise as a result of Test-First development.
Answer:
Test Driven Development (TDD) is software development approach in which
test cases are developed to specify and validate what the code will do. In simple
terms, test cases for each functionality are created and tested first and if the test
fails then the new code is written in order to pass the test and making code
simple and bug-free.
Test-Driven Development starts with designing and developing tests for every
small functionality of an application. TDD framework instructs developers to
write new code only if an automated test has failed. This avoids duplication of
code. The TDD full form is Test-driven development.

Following steps define how to perform TDD test,

1. Add a test.
2. Run all tests and see if any new test fails.
3. Write some code.
4. Run tests and Refactor code.
5. Repeat.

1. Add a test - In test-driven development, each new feature begins with

writing a test. This test must inevitably fail because it is written before the
feature has been implemented (if it does not fail, then the proposed new
 feature is obviated.) To write a test, the developer must clearly understand
the feature's specification and requirements. The developer can accomplish
this through use cases and user stories that cover the requirements and
exception conditions. This could also imply a variant, or modification of
an existing test. This is a differentiating feature of test-driven development
versus writing unit tests after the code is written: it makes the developer
focus on the requirements before writing the code, a subtle but important
difference.
2. Run all tests and see if the new one fails - This validates that the test
harness is working correctly and that the new test does not mistakenly pass
without requiring any new code. This step also tests the test itself, in the
negative: it rules out the possibility that the new test will always pass, and
therefore be worthless. The new test should also fail for the expected
reason. This increases confidence (although it does not entirely guarantee)
that it is testing the right thing, and will pass only in intended cases.
3. Write some code - The next step is to write some code that will cause the
test to pass. The new code written at this stage will not be perfect and may,
for example, pass the test in an inelegant way. That is acceptable because
later steps will improve and hone it. It is important that the code written is
only designed to pass the test; no further (and therefore untested)
functionality should be predicted and allowed for at any stage.
4. Run the automated tests and see them succeed - If all test cases now
pass, the programmer can be confident that the code meets all the tested
requirements. This is a good point from which to begin the final step of the
cycle.
5. Refactor code - Now the code can be cleaned up as necessary. By
rerunning the test cases, the developer can be confident that refactoring is
not damaging any existing functionality. The concept of removing
duplication is an important aspect of any software design. In this case,
however, it also applies to removing any duplication between the test code
and the production code.
6. Repeat - Starting with another new test, the cycle is then repeated to push
forward the functionality. The size of the steps should always be small,
with as few as 1 to 10 edits between each test run. If new code does not
rapidly satisfy a new test, or other tests fail unexpectedly, the programmer
 should undo or revert in preference to excessive debugging. Continuous
Integration helps by providing revertible checkpoints. When using external
libraries it is important not to make increments that are so small as to be
effectively merely testing the library itself unless there is some reason to
believe that the library is buggy or is not sufficiently feature-complete to
serve all the needs of the main program being written.

TDD RESULTS A&ALYSIS

TDD programming method was applied on SW development project at Ericsson.
The main reason for that was the conclusion that insufficient component testing
before delivery to integration tests was caused by deadline pressure that
commonly occur shortly before the deliveries. During such time pressure, people
tend to deliver the code with lower quality assurance. To address this problem, a
central part of the process change was to introduce component-level test-driven
development. The reason why TDD could make developers test more efficient is
that when writing the test cases before the code it is more likely that the written
tests are executed before delivery. From this analysis, a proposal for a concept
consisting of component-level test automation and TDD was made. The concept
was implemented into a new product release and results were compared with its
predecessors. During both projects personnel turnover was very low and the
development processes were stable. The chosen metric was Fault Slip Through
i.e. measuring the number of faults per specific phase especially highlighting the
fault slippage from different development phases. FST provides information
regarding the number of faults not detected in a certain activity. These faults
have instead been detected in a later activity. In this particular case slippage
from previous project phases to function and System tests was measured. Test
results are shown in the following table:

As can be seen from the table, slippage from Unit to Function test and from
Function to System test was reduced. Lower result in first case can be explained
by fact that one feature in Unit test was not fully following the new approach
(due to the specific test environment it was tested off-site) causing the higher
fault slippage than expected. Our future goal is further enhancing the TDD
practice in a away to include explicit estimation of the probability that the
software system performs according to its requirements. Some productivity
impact of such approach will also be examined.