Chapter 3 – Agile Software Development
Chapter 4 – Requirements Engineering

# Quiz

1. All agile methods suggest that software should be developed and delivered incrementally.

2. Match the Principle or Practice with their correct Descriptions

   1. Collective ownership

      The pairs of developers work on all areas of the system, so that no islands of expertise develop and all the developers take responsibility for all of the code. Anyone can change anything.

   2. Continuous integration

      As soon as the work on a task is complete, it is integrated into the whole system. After any such integration, all the unit tests in the system must pass.

   3. Incremental planning

      Requirements are recorded on “story cards,” and the stories to be included in a release are determined by the time available and their relative priority. The developers break these stories into development “tasks.”

   4. On-site customer

      A representative of the end-user of the system (the Customer) should be available full time for the use of the XP team. In an extreme programming process, the customer is a member of the development team and is responsible for bringing system requirements to the team for implementation

3. Match the Principle or Practice with their correct Descriptions

   1. Pair Programming

      Developers work in pairs, checking each other's work and providing the support to always do a good job.

   2. Refactoring

      All developers are expected to refactor the code continuously as soon as potential code improvements are found. This keeps the code simple and maintainable.

   3. Simple Design

      Enough design is carried out to meet the current requirements and no more

   4. Small Releases

      The minimal useful set of functionality that provides business value is developed first. Releases of the system are frequent and incrementally add functionality to the first release

4. Test automation is unwanted for test-first development

5. The functional requirements for a system are constraints on the services or functions offered by the system.

6. Non-functional requirements are constraints on the services or functions offered by the system.

7. Match the following process activities with their definitions

   1. Requirements discovery and understanding

      This is the process of interacting with stakeholders of the system to discover their requirements. Domain requirements from stakeholders and documentation are also discovered during this activity

   2. Requirements classification and organization

      This activity takes the unstructured collection of requirements, groups related requirements and organizes them into coherent clusters

   3. Requirements prioritization and negotiation

      This activity is concerned with prioritizing requirements and finding and resolving requirements conflicts through negotiation

   4. Requirements documentation

      Requirements are documented and input into the next round of the spiral. An early draft of the software requirements documents may be produced at this stage, or the requirements may simply be main- tained informally on whiteboards, wikis, or other shared spaces.

# Exercise

1. At the end of their study program, students in a software engineering course are typically expected to complete a major project. Explain how the agile methodology may be very useful for the students to use in this case.

   Agile methodology refers to a set of software development methods based on iterative development, in which requirements and solutions are developed through collaboration between self-organizing cross-functional teams. It can be seen that agile methods are team-centric, so they can help students communicate with each other. Agile methods also encourage staged releases so that teams can present updates to professors as they work.

2. Explain how the principles underlying agile methods lead to the accelerated development and deployment of software.

   Agile methods are used to deliver entire large projects in terms of small utilities and functions. Because agile focuses on developing a minimum viable product and then adding more features during development, developers can develop a working product faster than they would have had to have all the features in the first release.
   The principles underlying agile development are:

   1. Individual and interactions over processes and tools. By taking advantages of individual skills and ability and by ensuring that the development team knows what each other are doing, the overheads of formal communication and process assurance are avoided. This means that the team can focus on the development of working software.

   2. Working software over comprehensive documentation. This contributes to accelerated development because time is not spent developing, checking and managing documentation. Rather, the programmer’s time is focused on the development and testing of code.

   3. Customer collaboration over contract negotiation. Rather than spending time developing, analyzing and negotiating requirements to be included in a system contract, agile developers argue that it is more effective to get feedback from customer’s directly during the development about what is required. This allows useful functionality to be developed and delivered earlier than would be possible if contracts were required.

   4. Responding to change over following a plan. Agile developers argue (rightly) that being responsive to change is more effective than following a plan-based process because change is inevitable whatever process is used. There is significant overhead in changing plans to accommodate change and the inflexibility of a plan means that work may be done that is later discarded.

3. Extreme programming expresses user requirements as stories, with each story written on a card. Discuss the advantages and disadvantages of this approach to requirements description.

   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 on cards, for example many times user stories are stored online with agile project management tools.
   User stories are considered "placeholders for conversations", which are only short descriptions of user needs, and it is expected that the developers responsible for implementing user stories will further elaborate on the details based on the following to communicate directly with users.
   The main advantage of a user story is that it is short and concise, it expresses a need from the perspective of the user's business need, rather than trying to tell the developer how to meet that need.
   The downside is that it relies on direct communication to further detail the requirements, and some developers may not be very good at doing so. Sometimes a user story can be misunderstood and a developer can waste time finishing it and then just have to turn around and redo it.

4. In test-first development, tests are written before the code. Explain how the test suite may compromise the quality of the software system being developed.

   Test-first development requires a clear relationship between system requirements and code implementation. Writing tests starts with implicitly defining an interface and behavior specification for the functionality being developed. It is test-first programming in the process of writing tests and system requirements production, reducing the problem of requirements and interface misunderstandings.

   Test-first development helps programmers better understand system requirements to discover intended goals. If some error pops up while debugging, the same test might help to catch it again and again.

   Test-first development also has some drawbacks, such as when programming, it is difficult to predict how long debugging will take place, and sometimes debugging efforts will be in vain. Writing tests is difficult, it leads to complex user interfaces and reduces the workflow of programs in the system. Writing incremental test development is sometimes very difficult. May not be able to meet customer needs in a shorter period of time. Test-first development makes it difficult to judge the comprehensiveness of a set of tests. Although it is impossible for these tests to cover the entire system case. By the time the actual code is written, the test suite may be outdated and unable to test every vulnerability the code may have. If the tests are not reviewed, and further tests are written, there may be undetected bugs in the system version.

5. Suggest four reasons why the productivity rate of programmers working as a pair might be more than half that of two programmers working individually

   1. Pair programming leads to continuous informal review. This finds bugs faster than testing alone. Pair programming makes the code less buggy.

   2. Information sharing in pair programming is implicit - it happens during the process. This reduces the need for documentation and the time required if one programmer has to take over the work of another. Increase communication to discuss software before development and reduce false starts and rework. The number of bugs avoided by formal inspections allows less time to be spent fixing bugs during the testing phase.

   3. All code to be sent to production is co-created by two people on a single computer. Pair programming improves software quality without compromising delivery time. It's counter-intuitive, but 2 people working on one computer will add as much functionality as two separate jobs, only it will be of higher quality.

   4. Pair programming encourages refactoring. The code must be easily editable and enhanced for effectiveness, and the test code will output with unbiased results. This reduces the cost of subsequent development and changes and means that future changes can be made more quickly. Therefore, the efficiency is improved

6. Explain why agile methods may not work well in organizations that have teams with a wide range of skills and abilities and well-established processes.

   Agile methods are often used to develop small software products. Initially, small companies mainly used these methods. Over the past few years, a lot of work has been done to develop agile methods for large software products. But it is still difficult to use agile methods to develop new information systems in large projects for the following reasons:

   1. Larger systems are often more complex and harder to understand than smaller systems.
   2. Large systems are usually systems of systems composed of different teams to develop different parts of the system. These teams usually work in different locations. Therefore, it is impossible for every team to have a complete view of the system.
   3. The development process of large systems is limited by external rules and regulations. These require certain types of files. Therefore, it takes a lot of time to process.
   4. Large systems have different stakeholders with different goals. Therefore, it is not possible to involve all stakeholders in the development process.
      Therefore, it is difficult to use agile methods for large projects to develop a new information system that is part of an organized system of systems.

7. One of the problems of having a user closely involved with a software development team is that they “go native.” That is, they adopt the outlook of the development team and lose sight of the needs of their user colleagues. Suggest three ways how you might avoid this problem, and discuss the advantages and disadvantages of each approach

   1. Validation of recommendations given by users with different users: Recommendations given by users must be validated against recommendations given by any different users.

   Advantage:
   Helps to independently examine user suggestions by discussing them.

   Disadvantage:
   If it is recommended to discuss in a stand-alone way, it will slow down the progress of the software.
   If the project is delayed, it will incur additional costs for the project.

   2. Get advice from multiple users:
      Development teams must involve multiple users to get advice.

   Advantage:
   With multiple recommendations, you can gain multiple perspectives from different users on a specific problem.
   The probability of having any typical user will be reduced.

   Disadvantage:
   Recommendations from different users may be related.
   If dependencies rise, there will be additional costs to complete the project.

   3. Change team members:
      If any user suggestion is causing problems in the team. Then, change the user from the team.

   Advantage:
   With multiple suggestions, you can get multiple perspectives from different users.
   Helps to independently examine user suggestions by discussing them.

   Disadvantage:
   New users may not know the system. Therefore, he/she will take the time to understand the system and make recommendations.
   Independent review of user suggestions increases the production time of the project.
   If the project is delayed, it will incur additional costs for the project.