[Marte] The team builds a conceptual prototype in the first iteration. This helps the interaction between the team and the customer, so the team can do a better job documenting what the customer wants. The second iteration focuses primarily on understanding what technology to use and associated risks. Some of the key building blocks are outlined, and fragmented implementations of a couple of the critical use cases are done to better understand what technology choices to make.

[Ganymede] The project manager/architect spends a day writing a three-page VisionDocument. The team spends half a day in a brainstorming session to come up with an initial set of actors and use cases. Thirteen use cases are found, and each team member takes four to five use cases,spending 30 minutes to detail each use case. Then they get together and realize that they need another four use cases. They merge two use cases and eliminate one. They spend another two hours describing each of the four most critical use cases

[Marte] The project manager produces an 8-page Business Case and a 12-page Software Development Plan (SDP), referencing project plans, risks lists, and other key management artifacts. The project manager arranges a half-day review meeting with key stakeholders to walk through the Business Case, risk list, Vision, and Software Development Plan

[Marte] A lot of time will be spent on improving existing use cases, which means that fewer use cases will be critical than for green-field development. The architect identifies one of the existing use cases as critical because it involves using some unexplored new technology. The architect also identifies 2 of the 9 new use cases as being architecturally significant. The project manager identifies one additional use case as critical from the user perspective. The architect documents the 4 critical use cases in the SAD.

[Marte] The project manager and architect spend time with a mentor, who guides them in what process to use. Once the mentor understands the needs of the project, the mentor spends a few days producing a RUP configuration and writing a development case for the project. The development case covers the entire project (even though more detail is provided for the Inception phase). Once done, the mentor uses the development case to influence what is taught in the training delivered to the team.

[Ganymede] The architect proposes a list of 8 of the 40 use cases as being architecturally significant, strictly from a technical risk mitigation standpoint. The project manager suggests a set of 9 use cases that are critical to the stakeholders. The project manager would like stakeholder buy-in on the functionality of these as soon as possible. Five of the use cases overlap. After a few days of discussion between the architect and project manager, the project manager drops 2 use cases from the list (the project can delay getting feedback on those use cases from the users). The architect sees a way to mitigate some of the risks in 8 of the use cases through some of the use cases the project manager added. They end up with a joint list of 9 use cases, which the architect documents in the SAD.

[Júpiter] The team builds a functional prototype of the use case that is considered the most critical. The functional prototype identifies some key architectural components, including one that you need to purchase. The team builds bits and pieces of functionality to understand how some new technology can be used, allowing you to better understand what can be delivered.

[Marte] The team makes mock-ups of two of the four critical use cases identified. Half of this code is throw-away, but the mock-up convinces the team that it will be able to implement the use cases, and it gets some experience with some of the new technologies it will use. The team demonstrates the mock-ups to the customers and gauges the reactions of the audience to determine their expectations.

[Júpiter] The first iteration, the analysts, involving key stakeholders as necessary, spend roughly a week writing a first-draft Vision of eight pages. A lot of time is spent getting buy-in from all stakeholders. The team spends two days on a use-case workshop with eight key stakeholders, allowing them to come up with a good first-draft use-case model and glossary. In the second iteration, the team refines the Vision, which will be further refined later in the project, especially in Elaboration. They spend roughly four hours describing each of the nine most critical use cases. In conjunction with doing that, they make a number of updates to the use-case model.

[Ganymede] The team gets together and spends an hour agreeing on how it should work at large. After the meeting, the project manager/architect produces a RUP configuration that corresponds to what they agreed on and writes a one-page development case for the Inception phase, outlining which artifacts should be produced, what templates to use, and how to document the information. They decide to wait until the beginning of Elaboration to detail how to work in Elaboration. The project manager/architect, being more experienced, functions as a mentor for the rest of the team, helping them with the adoption of the process and tools.

[Júpiter] Compared to the first iteration, there is typically less business risk involved in developing the second generation of an application. Roughly the same process is followed as for the first project but with less rigor. The project manager writes a four-page Business Case and produces a Software Development Plan, referencing project plans, risk lists, and other key management artifacts. The project manager arranges a two-hour review meeting with key stakeholders to walk through the Business Case, risk list, Vision, and Software Development Plan.

[Júpiter] Most of the team members were involved when developing the first version of the application. They were happy with the process and tool environment, but had suggested a few improvements, which were documented at the end of the previous project. These suggestions for improvements are now implemented and rolled out to the team.

[Ganymede] The project manager/architect writes up a two-page memo, which functions as a business case, to the project sponsor. This provides the sponsor with sufficient information to understand the value of the expected investments.

[Júpiter] The team makes some updates to the existing Vision, clearly labeling what will be accomplished in the second generation, which is done in a day or two. Most of the time is spent on making an inventory of additional capabilities to implement and the known problems in the first system that must be fixed. The team tries to identify use cases that need to be added, and the most critical of the new use cases are detailed, with the team spending two to four hours on each of them. Planned improvements to existing use cases are listed, but these improvements are normally not detailed at this stage.

(ENADE 2011) O Processo Unificado (RUP – rational unified process) é um moderno processo de desenvolvimento de software constituído de quatro fases. Assinale a opção que apresenta as quatro fases do RUP, na ordem em que elas devem ser executadas.

O Processo Unificado de software é uma tentativa de aproveitar os melhores recursos e características dos modelos tradicionais de processo de software.

Sobre o Processo Unificado de software, assinale a afirmativa correta.

O RUP possui duas dimensões, uma representando o aspecto dinâmico do processo e a outra o aspecto estático do processo. Para tanto, no eixo vertical ela é representada:

As disciplinas do RUP (rational unified process) são

No RUP (Rational Unified Process) a disciplina denominada

No RUP (Rational Unified Process), é correto afirmar que a disciplina

São práticas recomendadas pelo Rational Unified Process: