UFMG - ICEx - DCC

DCC599 -- Engenharia de Produtos de Software II
2o. Semestre 2011  

Gabarito Provas
Notas

Livro texto:

Engenharia de Software

8ª Edição (9ª edição)

Ian Sommerville

Pearson 2007 (2011)

EPS 1                     1, 4, 6, 7, 8(UML), parcial(9,10), 17

EPS 2                     11, 13, 14, 16, 18, 19, 23

GPS 1&2               5, 7, 21, 22, 25, 26, 27,28, 29

              

               2?, 3?, 9?, 10?, 12?, 15?, 20? 24?, 30?, 31?, 32?

 

Bibliografia Complementar:
Engenharia de Software
Fundamentos, Métodos e Padrões
Terceira Edição
Wilson de Pádua Paula Filho
LTC - 2009
Sítio do livro:
http://dcc.ufmg.br/~wilson

Avaliação

4 Provas cada prova vale 35 pontos, escolhem-se as 3 melhores notas. Não há “reposição”.

Provas:
São escolhidas as 3 melhores notas caso o aluno faça as 4 provas. O objetivo de existir 1 prova adicional e serem escolhidas as 3 melhores notas é evitar que o professor tenha que fazer julgamento de mérito no caso de alunos que não podem comparecer em algum dia de prova. A possível melhoria de nota é um efeito colateral. As provas são sem consulta mas o aluno pode trazer uma folha de consulta que deverá ser entregue junto com a prova. A folha deve atender às seguintes restrições: (a) o tamanho máximo é o formato A4 (21,0x29,7); (b) não deve haver colagens, impressão etc somente elementos escritos à mão.

1a. Prova: 18/agosto/2011

2a. Prova: 23/agosto/2011

3ª. Prova: 24/agosto/2011

4ª. Prova: 29/agosto/2011

 

 Calendário

Data

Aula

Evento

Assunto

Agosto

 

 

 

10

01, 02, 03, 3.5

 

 Visão geral do conteúdo; Cap. 11

11

04, 05, 06, 07

 

Cap. 13

16

08, 09, 10, 10,5

 

Cap. 14

17

11, 12, 13, 14

 

Cap. 16

18

15, 16, 17, 17.5

 

Cap. 17; 1ª. prova

22

18, 19, 20, 21

 

Rev. Cap. 18,

23

22, 23, 24, 24.5

 

Cap. 19; 2ª. prova

24

25, 26, 27, 28

 

Cap.23; 3ª. prova

29

29, 30

 

4ª. prova

 

 

 

 

Disciplina: DCC599: Engenharia de Produtos de Software II
Carga Horária: 30 horas

Ementa


Conceitos introdutórios e básicos de Engenharia de Software.Utilização de processo e projeto na produção de sistemas de software.Atividades de desenvolvimento com foco no domínio da solução do problema: disciplinas de Arquitetura, Desenho, Testes e Implementação.

Programa

 

 

Bibliografia Principal

Ian Sommerville, Engenharia de Software, Pearson Addison-Wesley, 2007 (2011)

Bibliografia Complementar:

1.      Wilson de Padua Paula Filho, Engenharia de Software: Fundamentos, Métodos e Padrões, LTC Editora. 3ª. Edição, 2009.

2.      Grady Booch, Ivar Jacobson e James Rumbaugh. The Unified Modeling Language User Guide. Addison-Wesley, 2nd edition, 2005.

3.      Martin Fowler e Kendall Scott. UML Distilled Applying the Standard Object Modeling Language. Addison-Wesley, 3rd edition, 2003.

4.      IEEE. IEEE Standards Collection - Software Engineering.

5.      Ivar Jacobson, James Rumbaugh e Grady Booch. Unified Software Development Process. Addison-Wesley, 1999.

6.        James Rumbaugh, Ivar Jacobson e Grady Booch. Unified Modeling Language Reference Manual. Addison-Wesley, 2nd edition, 2004.

1.        Kent Beck, Extreme Programming Explained: embrace change, Addison-Wesley, 1999

2.        Kent Beck e Cynthia Andres, Extreme Programming Explained: embrace change, Addison-Wesley, second edition, 2004

 

Architects

Architects on an XP team look for and execute large-scale refactorings, write system-level tests that stress the architecture, and implement stories. Architects apply their expertise a little bit at a time throughout the project. They direct the architecture of the project throughout its evolution. The architecture for a little system should not be the same as for a big system. While the system is little the architect makes sure the system has just the right little architecture. As the system grows, the architect makes sure the architecture keeps pace.

 

Making big architectural changes in small, safe steps is one of the challenges for an XP team. The principle of the alignment of authority and responsibility suggests that it is a bad idea to give one person the power to make decisions that others have to follow without having to personally live with the consequences. Architects sign up for programming tasks just like any programmer. However, they are also on the lookout for big changes that have big payoffs.

 

Tests can communicate architectural intent. I talked with the architect of a major credit card processor who said that in such a high-capacity environment you don't want any architecture that might get in the way. To achieve this his team had a sophisticated stress testing environment. When they wanted to improve the architecture they would first improve the stress tests until the system broke. Then they would improve the architecture just enough to run the tests.

 

I suggested this strategy to an architect at another company. He complained of spending all of his time writing specifications and then explaining them to developers. He was frustrated that he didn't have time to code any more. I suggested he write a testing infrastructure and then use tests instead of specifications and explanations. If he saw a hole in a design he should write a failing test to point it out. I wasn't able to convince him to try the idea, but I still think it's valuable.

 

Another task for architects on an XP team is partitioning systems. Partitioning isn't an up-front, once-and-for-all task, though. Rather than divide and conquer, an XP team conquers and divides. First a small team writes a small system. Then they find the natural fracture lines and divide the system into relatively independent parts for expansion. The architects help choose the most appropriate fracture lines and then follow the system as a whole, keeping the big picture in mind as the groups focus on their smaller section.

Interaction Designers

Interaction designers on an XP team choose overall metaphors for the system, write stories, and evaluate usage of the deployed system to find opportunities for new stories. Addressing the concerns of eventual users is a priority for the team. The tools of interaction design, such as personas and goals, help the team analyze and make sense of the world of the user, although they are no substitute for conversation with real people.

Much advice for interaction designers is based on a phasist model of development: first interaction designers figure out what the system is supposed to do, and then programmers go make it do that. Phases reduce feedback and restrict the flow of value. Mutual benefit is possible between interaction design and the rest of an XP team without separating development into phases.

On an XP team, interaction designers work with customers, helping to write and clarify stories. Interaction designers can use all their usual tools during this process. They also analyze actual usage of the system to decide what the system needs to do next. Interaction designers specify a little bit up front and continue to refine the user interface throughout the life of the project.

Testers

Testers on an XP team help customers choose and write automated system-level tests in advance of implementation and coach programmers on testing techniques. On XP teams much of the responsibility for catching trivial mistakes is accepted by the programmers. Test-first programming results in a suite of tests that help keep the project stable. The role of testers shifts to early in development, helping define and specify what will constitute acceptable functioning of the system before the functionality has been implemented.

In Weekly Cycle, the first thing that happens to the chosen stories is that they are turned into automated system-level tests. This is one leveraged place for strong testing skills. Customers may have a good idea of the general behavior they want to see, but testers are good at looking at "happy paths" and asking what should happen if something goes wrong. "Okay, but what if login fails three times? What should happen then?" In this role testers amplify communication. They ensure that the system-level tests succeed only when the stories are fully implemented and ready for deployment.

Once the tests for the week are written and failing, testers continue to write new tests as implementation uncovers new details that need to be specified. Testers can also work to further automate and tune tests. Finally, when a programmer gets stuck on a knotty testing problem, a tester can pair with the programmer to help solve the problem.

Product Managers

In XP, product managers write stories, pick themes and stories in the quarterly cycle, pick stories in the weekly cycle, and answer questions as implementation uncovers under-specified areas of stories. A product manager doesn't just pick a bunch of stories at the beginning of the project and then sit back. A plan in XP is an example of what could happen, not a prediction of what will happen.

When the team has overcommitted, the product manager helps the team decide priorities by analyzing the differences between actual and assumed requirements. The product manager adapts the story and theme to what is really happening now.

Stories should be sequenced for business, not technical, reasons. The goal is a working system from the first week. Product managers don't necessarily start at the beginning and work through to the end. I talked to the product manager for a planning tool. He wanted to try the editing features first. The programmers didn't think it made sense to modify information before the user could enter it in the first place. Since editing was the most valuable part of the product, the product manager defined a dummy data set that could be entered manually by the programmers. Then everyone could see what editing was like. This gave the whole team an early look at the heart of the product and gave them plenty of time to refine it.

The system should be "whole" at the end of the first weekly cycle. If you plan to process images, you should be able to process an image at the end of the first week. The product manager picks stories to make this happen.

Product managers encourage communication between customers and programmers, making sure the most important customer concerns are heard and acted on by the team. If the team is practicing Real Customer Involvement, product managers are responsible for encouraging the system to grow in a way that meets the particular needs of the customers who are picking stories as well as the market as a whole.

Roles

Roles on a mature XP team aren't fixed and rigid. The goal is to have everyone contribute the best he has to offer to the team's success. At first, fixed roles can help in learning new habits, like having technical people make technical decisions and business people make business decisions. After new, mutually respectful relationships are established among the team members, fixed roles interfere with the goal of having everyone do his best. Programmers can write a story if they are in the best position to write the story. Project managers can suggest architectural improvements if they are in the best position to suggest architectural improvements.

In saying that the above roles can contribute to an XP team, I don't mean to imply that there is a simple mapping from one person to one role. A programmer may be a bit of an architect. A user may grow into a product manager. A technical writer can also test. The goal is not for people to fill abstract roles, but for each team member to contribute all he can to the team.

As the team matures, keep in mind the alignment of authority and responsibility. Everyone on the team can recommend changes, but they should be prepared to back up their concerns with action.