O GoConqr está de visual novo! Conte para nós o que você achou.

Mapa mental

Chapter 3: Agile Software Development (3705)

Gideon Van Computer Science Inglês

Chapter 3: Agile Software Development (3705)

Conteúdo do mapa

Chapter 3: Agile Software Development (3705)

  1. Agile methods

    • Rapid software development became known as agile development or agile methods
    • The processes of specification, design and implementation are interleaved. no detailed system specification, and design documentation is minimized
    • The system is developed in a series of increments
    • Extensive tool support is used to support the development process. automated testing tools, tools to support configuration management, and system integration
    • Agile Manifesto
    • Agile methods have been particularly successful for two kinds of system development.
      • Product development where a software company is developing a small or medium-sized product for sale
      • Custom system development within an organization, where there is a clear commitment from the customer
  2. Agile development techniques

    • XP
      • Extreme Programming as originally proposed has proved to be more difficult than anticipated
        • cannot be readily integrated with the management practices and culture of most businesses
        • they are used in conjunction with a management focused agile method such as Scrum
      • In XP, requirements are expressed as scenarios (called user stories),
      • several new versions of a system may be developed by different programmers, integrated, and tested in a day.
      • most significant contribution is probably the set of agile development practices that it introduced to the community
        • User Stories
          • the idea of “user stories” was developed where a user story is a scenario of use that might be experienced by a system user.
          • User stories may be used in planning system iterations
            • estimates the effort and resources required for implementing each task.
            • identify useful functionality that can be implemented in about two weeks, when the next release of the system is made available to the customer.
            • The principal problem with user stories is completeness. Have there been enough stories to cover the functionality of the system
        • Refactoring
          • Design for change is a traditional software principle
            • Extreme programming, however, has discarded this principle on the basis that designing for change is often wasted effort
          • Refactoring (Fowler et al. 1999) means that the programming team look for possible improvements to the software and implements them immediately
          • Refactoring improves the software structure and readability and so avoids the structural deterioration that naturally occurs when software is changed.
          • refactoring is part of the development process, the software should always be easy to understand and change as new requirements are proposed.
        • Test-first development
          • incremental development have a very informal testing process, in comparison with plan-driven testing
            • Extreme Programming developed a new approach to program testing to address the difficulties of testing without a specification.
          • The key features of testing in XP are:
            • test-first development,
              • . Test-first development requires there to be a clear relationship between system requirements and the code implementing the corresponding requirements.
              • relationship is clear because the story cards representing the requirements are broken down into tasks and the tasks are the principal unit of implementation
              • it also avoids the problem of “test-lag.”. Developer produces code faster than tester producing tests. Leads to tests being skipped
            • incremental test development from scenarios,
            • user involvement in the test development and validation,
            • the use of automated testing frameworks.
              • Test automation is essential for test-first development
            • test-driven development techniques
              • write the tests before you write the code
                • run the test as the code is being written and discover problems during development.
          • there are problems in ensuring that test coverage is complete:
            • Programmers prefer programming to testing, and sometimes they take shortcuts when writing tests. may write incomplete tests that do not check for all possible exceptions that may occur.
            • Some tests can be very difficult to write incrementally
        • Pair programming
          • programmers work in pairs to develop the software.
          • Pair programming has a number of advantages.
            • It supports the idea of collective ownership and responsibility for the system
            • It acts as an informal review process because each line of code is looked at by at least two people.
              • effective in discovering a high percentage of software errors
            • It encourages refactoring to improve the software structure.
            • Junior programmer benefits from this and produce better code. Experienced programmers show inefficiency
          • In a given time, a pair of developers would produce half as much code as two individuals working alone.
            • Often rejected because of this by organisations
  3. Agile project management

    • agile development has to be managed so that the best use is made of the time and resources available
      • the Scrum agile method was developed (Schwaber and Beedle 2001; Rubin 2013) to provide a framework for organizing agile projects and, to some extent at least, provide external visibility of what is going on
    • does not mandate the use of specific development practices such as pair programming and test-first development
    • follows the principles from the agile manifesto
    • Scrum Process
      • The starting point for the Scrum sprint cycle is the product backlog
    • the things that users like about the Scrum method are:
      • The product is broken down into a set of manageable and understandable chunks that stakeholders can relate to.
      • Unstable requirements do not hold up progress
      • The whole team has visibility of everything, and consequently team communication and morale are improved
      • Customers see on-time delivery of increments and gain feedback on how the product works
      • Trust between customers and developers is established,
    • Distributed Scrum
  4. Scaling agile methods

    • Scaling agile methods has closely related facets:
      • Scaling UP these methods to handle the development of large systems that are too big to be developed by a single small team.
      • Scaling OUT these methods from specialized development teams to more widespread use in a large company that has many years of software development experience
      • organization moving to agile methods can expect to see productivity improvement across the organization of about 15% over 3 years, with similar reductions in the number of product defects
    • Practical problems with agile methods
      • For large, long-lifetime systems, agile methods presents problems
        • The informality of agile development is incompatible with the legal approach to contract definition that is commonly used in large companies
        • Agile methods are most appropriate for new software development rather than for software maintenance
        • Agile methods are designed for small co-located teams, yet much software development now involves worldwide distributed teams.
        • Three types of problems can arise in maintaining a custom system:
          • lack of product documentation
          • keeping customers involved
          • development team continuity
    • Agile and plan-driven methods
      • A fundamental requirement of scaling agile methods is to integrate them with plandriven approaches.
    • Agile methods for large systems
      • Agile methods have to evolve to be used for large-scale software development. The fundamental reason for this is that large-scale software systems are much more complex and difficult to understand and manage relative to small systems
        • Six principal factors (Figure 3.13) contribute to this complexity:
      • IBM has also developed a framework for the large-scale use of agile methods called the Agile Scaling Model (ASM).
        • There is no one model fits all. Requirements and composition changes per prject
          • approaches to scaling agile methods have a number of things in common:
            • A completely incremental approach to requirements engineering is impossible
              • Some early work on initial software requirements is essential.
              • requirements should not normally be specified in detail; details are best developed incrementally.
            • There cannot be a single product owner or customer representative
            • It is not possible to focus only on the code of the system. You need to do more up-front design and system documentation. Architectural and schema design
            • Cross-team communication mechanisms have to be designed and used
            • Continuous integration, where the whole system is built every time any developer checks in a change, is practically impossible
              • However, it is essential to maintain frequent system builds and regular releases of the system.
      • Scrum has been adapted for large-scale development.
        • Role replication -> Each team has a Product Owner for its work component and Scrum Master
        • Product architects -> Each team chooses a product architect, and these architects collaborate
        • Release alignment -> The dates of product releases from each team are aligned
        • Scrum of Scrums There is a daily Scrum of Scrums where representatives from each team meet to discuss progress, identify problems, and plan the work
    • Agile methods across organizations
      • It can be difficult to introduce agile methods into large companies for a number of reasons:
        • Project managers who do not have experience of agile methods may be reluctant to accept the risk of a new approach,
        • Large organizations often have quality procedures and standards that all projects are expected to follow
        • Agile methods seem to work best when team members have a relatively high skill level.
        • There may be cultural resistance to agile methods
  5. important differences between incremental development and plan-driven development is in the way that the system is tested.

Imagens e arquivos do mapa

  • Chapter 3: Agile Software Development (3705)
  • Chapter 3: Agile Software Development (3705)
  • Chapter 3: Agile Software Development (3705)
  • Chapter 3: Agile Software Development (3705)
  • Chapter 3: Agile Software Development (3705)
  • Chapter 3: Agile Software Development (3705)
  • Chapter 3: Agile Software Development (3705)
  • Chapter 3: Agile Software Development (3705)
  • Chapter 3: Agile Software Development (3705)

Informações

Descrição
Computer Science Mapa Mental sobre Chapter 3: Agile Software Development (3705), criado por Gideon Van em 14-01-2019.
Criado por
Gideon Van · jan 2019
Atualizado
5 mai 2019
Visualizações
1
Avaliação

Fale Conosco

Sobre o que é sua mensagem?

O que você acha do novo visual?

Você gostou?