Engenharia
de
Software
INF1629
Resumo 01
“1ª Semana”
Grupo _Underscore
Grupo _Underscore
Versão: 1.0
Data: 09/08/2005
2 de 10
SUMÁRIO
1. O Que Aprendi:.............................................
Grupo _Underscore
Versão: 1.0
Data: 09/08/2005
3 de 10
1. O Que Aprendi:
De início foi explica? como seria o funcionamento...
Grupo _Underscore
Versão: 1.0
Data: 09/08/2005
4 de 10
3. O Que Duvido:
Um ponto que vale mencionar é sobre o software não...
Grupo _Underscore
Versão: 1.0
Data: 09/08/2005
5 de 10
4. Sobre Edsger Wybe Dijkstra
O professor Edsger Wybe Dijkstra, um ...
Grupo _Underscore
Versão: 1.0
Data: 09/08/2005
6 de 10
que somente você pode fazer"; e sua observação em sua palestra da c...
Grupo _Underscore
Versão: 1.0
Data: 09/08/2005
7 de 10
5. Resumo do artigo “Ensino de Engenharia de Software: Relato de
Ex...
Grupo _Underscore
Versão: 1.0
Data: 09/08/2005
8 de 10
O processo XP não prioriza a documentação do projeto de software as...
Grupo _Underscore
Versão: 1.0
Data: 09/08/2005
9 de 10
40 horas por semana: ninguém do time trabalha mais que 40 horas por...
Grupo _Underscore
Versão: 1.0
Data: 09/08/2005
10 de 10
6. Bibliografia consultada
• “Ensino de Engenharia de Software: Re...
Próximos SlideShares
Carregando em…5
×

Rel1 2

375 visualizações

Publicada em

Publicada em: Turismo, Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
375
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
2
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Rel1 2

  1. 1. Engenharia de Software INF1629 Resumo 01 “1ª Semana” Grupo _Underscore
  2. 2. Grupo _Underscore Versão: 1.0 Data: 09/08/2005 2 de 10 SUMÁRIO 1. O Que Aprendi:................................................................................................... 3 2. O Que Não Entendi:............................................................................................ 3 3. O Que Duvido: .................................................................................................... 4 4. Sobre Edsger Wybe Dijkstra.............................................................................. 5 5. Resumo do artigo “Ensino de Engenharia de Software: Relato de Experiências” ................................................................................................................ 7 6. Bibliografia consultada..................................................................................... 10 7. Grupo _Underscore .......................................................................................... 10 Deleted: 27/08/2004
  3. 3. Grupo _Underscore Versão: 1.0 Data: 09/08/2005 3 de 10 1. O Que Aprendi: De início foi explica? como seria o funcionamento do curso, o que seria visto e o critério de aprovação no mesmo. Foi explica como seria o trabalho e quais tecnologias estariam envolvidas, neste caso: Linux, Apche, MySQL e PHP. Após a introdução ao curso foi dada as características de software e hardware, e foi dada ênfase à percepção do que é software frente ao que este realmente é. Foi visto o “dilema” da Engenharia de Software, que é qualidade versus custo. Foi visto a diferenças entre o processo clássico e XP (Programação Extrema), bem como o que cada um te de bom e ruim. Em seguida foi abordado o que seria programação por fricção, e como esta “técnica” deve ser evitada pela sua baixa produtividade. E por fim, foi dada um pouco da história da Engenharia de Software, que teve início de pesquisas sobre o assunto por volta de 1968 pelo departamento de defesa da OTAN (Organização do Tratado do Atlântico Norte), e que hoje é normatizada pelo IEEE (Instituto de Engenharia Elétrica e Eletrônica dos EUA). E os comentários que fizemos sobre software grandes, tipo Office ou XP da Microsoft. Porque citamos o Prof. Dijkstra? .... 2. O Que Não Entendi: O que não aprendi, mas também porque não era esse o intuito, pelo menos por enquanto, foi como utilizar o XP como técnica de desenvolvimento de um sistema. Pois esse assunto ainda está para ser abordado com suficiente profundidade mais à frente. Visão clássica • Definição • Arquitetura • Implementação XP • Planejamento • Teste • Codificação • Desenho (Refactoring) Deleted: 27/08/2004
  4. 4. Grupo _Underscore Versão: 1.0 Data: 09/08/2005 4 de 10 3. O Que Duvido: Um ponto que vale mencionar é sobre o software não ser fácil de mudar. Isso pode não ser absoluto, pois um programa pode ser mais ou menos complexo de se alterar mesmo sem levar em conta o tamanho. Pois existem técnicas e ferramentas que permitem que o código ou parte dele seja facilmente alterável; o que mesmo assim tem um limite de facilidade. Talvez a questão seja mais se o software é ou não viável de alteração; pois um sistema complexo feito sem nenhuma preocupação com futuras modificações pode ser inviável de se alterar devido ao longo tempo de trabalho de re-entendimento deste. Mas este mesmo sistema poderia ser modificado com certa facilidade num dado tempo. Veja o ponto básico é justamente o que você levantou. Aparentemente, porque tenho facilidades de acesso e de ferramentas para efetuar a mudança e algumas outras para testar, pode parecer um processo (o de alteração) simples. No entanto, e isso é o que queríamos ressaltar, quando o volume de linhas envolvidas é grande aumenta a possibilidade de alterarmos indevidamente, gerando então problemas em função da complexidade resultante do volume de informações. Deleted: 27/08/2004
  5. 5. Grupo _Underscore Versão: 1.0 Data: 09/08/2005 5 de 10 4. Sobre Edsger Wybe Dijkstra O professor Edsger Wybe Dijkstra, um pioneiro notável da ciência e da indústria da computação, faleceu após uma longa luta contra o câncer em 6 de agosto de 2002 em Nuenen, nos Países Baixos. Dijkstra nasceu em 1930 em Rotterdam, filho de um pai químico e uma mãe matemática. Graduou-se no gymnasium Erasmianum em Rotterdam e obteve graduações na matemática e na física teórica da universidade de Leyden, e um Ph.D. em ciência da computação da universidade de Amsterdã. Trabalhou como programador no centrum de Mathematisch, Amsterdã, 1952-62; era professor da matemática, universidade de Eindhoven da tecnologia, 1962-1984; e era um companheiro da pesquisa da corporação de Burroughs, 1973-1984. Deteve a cadeira centennial de Schlumberger em ciências da computação na universidade de Texas em Austin, 1984- 1999, e aposentou-se como professor Emeritus em 1999. A Dijkstra foi concedido em 1972 o prêmio ACM Turing, visto freqüentemente como o prêmio de Nobel para computação. Era membro da academia real de artes e ciências dos Países Baixos, da academia de artes e ciências americana, e de um distinto companheiro da sociedade britânica de computação. Recebeu em 1974 o prêmio AFIPS Harry Goode, em 1982 o prêmio de pioneiro da computação do IEEE, e em 1989 o prêmio ACM SIGCSE para contribuições proeminentes à instrução da ciência da computação. A universidade de Atenas de economia concedeu-lhe um doutorado honorário em 2001. Em 2002, a fundação de C&C de Japão reconheceu Dijkstra "por suas contribuições abrindo caminho ao estabelecer base científica para o software de computador com a pesquisa criativa da teoria básica do software, da teoria do algoritmo, da programação estruturada, e dos semáforos". Dijkstra é reconhecido por suas contribuições à metodologia matemática. É responsável pela idéia de construção de sistemas operacionais como processos seqüenciais explicitamente sincronizados, pelo desenvolvimento formal de programas de computador, e para as fundações intelectuais para o controle disciplinado do não determinismo. É bem conhecido por seu algoritmo de caminho mais curto surpreendentemente eficiente e por ter projetado e codificado o primeiro compilador do Algol 60. Era notoriamente o líder da abolição do comando GOTO na programação. Dijkstra era um escritor prodígio. Sua coleção inteira de mais de mil e trezentos trabalhos manuscritos foi digitalizada e estão acessíveis em http://www.cs.utexas.edu/users/EWD . Correspondeu-se também regularmente com as centenas dos amigos e dos colegas através dos anos, não por email, mas por cartas convencionais, as quais tinha maior gosto. Dijkstra era notório por sua sagacidade, eloqüência, e a intimidade com palavras, como em sua observação "a pergunta de se os computadores podem pensar é como a pergunta de se os submarinos podem nadar"; seu conselho a um pesquisador promissor, que perguntou como selecionar um tópico para a pesquisa: "faça somente o Deleted: 27/08/2004
  6. 6. Grupo _Underscore Versão: 1.0 Data: 09/08/2005 6 de 10 que somente você pode fazer"; e sua observação em sua palestra da concessão de Turing "em sua capacidade como uma ferramenta, computadores será mais um ripple na superfície de nossa cultura. Em sua capacidade como o desafio intelectual, são sem precedentes na historia cultural da humanidade". Dijkstra enriqueceu a língua de computar ?com muitos conceitos e frases, como a programação estruturada, separação dos interesses, sincronização, deadlock, jantar dos filósofos, a precondição mais fraca, o comando “stored”, o milagre excluído, e os " famosos semáforos " para controlar processos de computador. O dicionário inglês de Oxford cita seu uso das palavras "vetor" e "pilha" em um contexto de computação. Dijkstra apreciava tocar Mozart para seus amigos em seu piano Boesendorfer. Ele e sua esposa tinaham um gosto por explorar os parques nacionais em sua caminhonete Volkswagen, chamada a “máquina de Turing”, na qual escreveu muitos trabalhos técnicos. Durante todo sua carreira científica, Dijkstra formulou e perseguiu ideais acadêmicos de mais elevados rigores científicos, desvinculado de considerações comerciais ou políticas. Simplicidade, beleza, e eloqüência eram seus pontos fortes, e sua insistência na elegância na programação e na matemática eram uma inspiração a milhares. Julgou seu próprio trabalho por padrões mais elevados e lançou um desafio a seus muitos amigos para fazerem.. o mesmo. Na passagem de Dijkstra, deixe-nos recordar a observação da divisão de Phaedo sobre Sócrates: "nós podemos verdadeiramente dizer que de todos os homens de seu tempo, ele era o mais sábio, o mais justo e o melhor”. Gostei do empenho, no entanto o objetivo era um pequeno resumo e não necessariamente uma tradução. Deleted: 27/08/2004 Formatted: Highlight
  7. 7. Grupo _Underscore Versão: 1.0 Data: 09/08/2005 7 de 10 5. Resumo do artigo “Ensino de Engenharia de Software: Relato de Experiências” Colar aqui o resumo do artigo...??? O artigo relata a experiência adquirida com um método de ensino aplicado à disciplina Princípios de Engenharia de Software. Apresentando aspectos teóricos e oferecendo uma experiência prática da aplicação desses conceitos, o método visa despertar o interesse dos alunos em engenharia de software. Nessa experiência prática é adotada uma filosofia de desenvolvimento cooperativo, baseado no processo Extreme Programming (XP). Foi constatado entre os docentes que é necessário, nas disciplinas de informática, que se façam trabalhos práticos para que os alunos assimilem melhor o conhecimento transferido. Na disciplina Engenharia de Software, os estudos de casos enfatizam a aprendizagem de aspectos tecnológicos tais como linguagens de especificação, métodos e ferramentas de apoio, deixando de serem trabalhados os aspectos sociais do desenvolvimento, tais como cooperação e comunicação entre os desenvolvedores. O método utilizado para ensino de PES aborda os dois aspectos, técnico e social. Para isso é utilizado o processo de desenvolvimento XP modificado e alguns métodos de apoio. O processo XP é um método ágil, enfatizando aspectos humanos do desenvolvimento de software. Como esse processo é mais dinâmico que os tradicionais, ele possibilita que os integrantes das equipes de desenvolvimento desempenhem diferentes papeis e trabalhem em grupos maiores, o que é um cenário real durante o desenvolvimento de um software. O método de trabalho da disciplina consiste em uma primeira fase com aulas expositivas nas quais os alunos são levados a construírem seu próprio conhecimento fazendo resumos dos assuntos da semana. É iniciado também uma familiarização com o ambiente WEB, pois os resumos são entregues através da página da disciplina. No final dessas aulas teóricas os alunos são submetidos à primeira prova. Para aplicar esses conceitos aprendidos em um cenário real de desenvolvimento de software foi selecionado um processo de desenvolvimento e uma aplicação para oferecer uma maior qualidade de conhecimento teórico e prático sobre Engenharia de Software. O método XP foi escolhido por sua aplicabilidade em projetos pequenos e ele é o que melhor se adequa ao nível de proficiência dos alunos. Esse método possibilita uma maior dinamicidade nos papéis assumidos, trazendo os resultados mais rapidamente e fazendo com que os alunos experimentem diferentes papéis no desenvolvimento do software. Deleted: 27/08/2004 Formatted: Highlight
  8. 8. Grupo _Underscore Versão: 1.0 Data: 09/08/2005 8 de 10 O processo XP não prioriza a documentação do projeto de software assim foi escolhida uma ferramenta para a modelagem de requisitos através da descrição dos termos do Léxico e de Cenários. Na segunda parte do curso, o processo XP é mostrado e é definida a maneira que os alunos vão trabalhar. A turma é dividida formando duas equipes compostas por um gerente, um historiador, e pares de programadores, sendo dado um nome a essa equipe. As aulas passam a serem dadas no laboratório e começam a serem como reuniões, os alunos podem conversar com o cliente e o consultor. No laboratório os alunos têm acesso a um servido WEB baseado nas linguagens PHP, HTML e XML e o banco de dados MYSQL ou PostgreSQL instalados. Cada equipe possui apenas uma conta nesse servidor podendo somente acessa-lo através de FTP. É possível usar a internet para consulta e até mesmo cópia de programas antigos, possibilitando que os alunos vejam as vantagens do reuso e o quanto é complicado evoluir em um sistema que eles não desenvolveram e não foi devidamente documentado. Extreaming Programing – processo de desenvolvimento de software definido por quatro atividades: Planejamento, Teste, Implementação e Desenho. Planejamento: requisitos coletados e negociados com cliente Testes: elabora os testes a partir dos dados coletados com o cliente Implementação: codifica atendendo aos testes Desenho: redesenha o sistema a medida que novas funcionalidades são incorporadas Princípios: Jogo do Planejamento: determina escopo da próxima versão, define prioridades e estipula estimativas. Pequenas versões: visa produzir um sistema simples rapidamente e subdivide todo o sistema em versões de ciclos muito peuqenos. Refactoring: reconstrução do sistema sem alterar o seu comportamento, evita retrabalho e melhora a comunicação. Programação em pares: dois programadores em cada maquina, e os pares mudam a cada ciclo. Propriedade coletiva: qualquer pessoa pode mudar o código em qualquer tempo. Integração contínua: visa integrar e reconstruir o sistema muitas vezes por dia, sempre que uma tarefa é finalizada. Deleted: 27/08/2004
  9. 9. Grupo _Underscore Versão: 1.0 Data: 09/08/2005 9 de 10 40 horas por semana: ninguém do time trabalha mais que 40 horas por semana, para melhor produtividade. Cliente on-site: o cliente deve fazer parte do time e poder responder questões. Metáfora: ajuda o time a ter o mesmo entendimento sobre o vocabulário utilizado pelo domínio do projeto, e ajuda na nomeação de funções. o Editor de Cenários e Léxico em hiper-texto”. o Cenários: técnica de modelagem de requisitos. Descrevem situações do mundo real dentro de um contexto. Estes não são descartados depois, pois servem para fazer estimativas e elaborar os testes de aceitação. Padrões de codificação: todos devem seguir os padrões estipulados pelo time, e dar ênfase a comunicação via código. Deixando o código como única documentação mantida no processo. Desenho simples: sempre que possível simplificar ao máximo o sistema. Teste contínuo: os programadores executam testes durante o processo de desenvolvimento. Cenários: Título Objetivo Atores Recursos Contexto Restrições Episódios Exceções Deleted: 27/08/2004
  10. 10. Grupo _Underscore Versão: 1.0 Data: 09/08/2005 10 de 10 6. Bibliografia consultada • “Ensino de Engenharia de Software: Relato de Experiências” – link. • Biografia e manuscritos do Prof. Edsger Wybe Dijkstra disponíveis no site da Universidade do Texas. • Notas de aula do Prof. Julio César Sampaio do Prado Leite (INF1629, Engenharia de Software). 7. Grupo _Underscore • Eduardo Martins Machado ...................................................... 0014696-3 • Luiz Diogo Rangel Salles ........................................................ 0014704-9 • Thiago Crispino Santos ........................................................... 0014683-8 • Rodrigo Buás Lopes ................................................................ 0016829-? Deleted: 27/08/2004

×