O documento discute a engenharia da web, incluindo seus atributos, características e diferenças em relação à engenharia de software tradicional. Também aborda as camadas da engenharia da web, incluindo processos, métodos e ferramentas, com foco nos princípios básicos de teste de software para aplicações web.

1. RUP e Métodos Ágeis...Márcia Rodrigues marciarodrigues.imed.edu.brmarcia@imed.edu.br

2. Mestrado com ênfase em gestão do conhecimento através dos Ambientes Virtuais de Aprendizagem. Especialista em Desenvolvimento de Software com foco em métodos ágeis e riscos de projetos de desenvolvimento de softwares.Professora, consultora e coordenadora da Universidade Corporativa da IMED.Autora do Livro Modelo ESTRELA.Atualmente ministra aulas de engenharia, gestão de projetos e Análise UML na IMED , Unisinos e na Universidade Corporativa da Petrobrás (RJ e BH)Informações sobre a Professora

3. Ementa: Apresentar a evolução, a terminologia e o estado da arte da Engenharia de Software. Dar uma visão geral dos fatores críticos que afetam a Engenharia de Software. Apresentar o RationalUnifiedProcess e o eXtremeProgramming. Tendências em Engenharia de Software.Objetivos da Disciplina

4. Modalidade do cursoAulas expositivas porém.....Com muita interação: questionar,

5. agregar experiências,

6. estabelecer discussões a qualquer momento!O QUE VOCÊ PERCEBE?5

7. 6E agora ?

8. Examine esta imagem: O que você pode achar? Olhe de longe... Olhe de perto...7

9. Situação Atual das Organizações

10. 9 a comunicação entre o usuário e o desenvolvedor de software normalmente é muito fracaCARACTERÍSTICAS DE UMA EQUIPE EFICAZObjetivo bem definidoAtenção no ouvirParticipaçãoDivergênciaCivilizadaDecisões deConsensoInformalidadeComunicação AbertaLiderança CompartilhadaAtribuiçõesbem definidasRelaçõesExternas Auto-avaliação

11. PROCESSO DE GESTÃO DA MUDANÇAComunicação em duas vias SuportetécnicoCelebraçãoTreinamentoenvolvimentoComunicação emduas vias Informação“Eu faço”“Eu posso”“Eu acredito”“Eu entendo”SAP“EU sei”

12. Relação com as demais disciplinasEngenharia de software (Trad. e Web)Requisitos de softwareGerenciamento de projetosProjetos de DesenvolvimentoRiscos de Projetos

13. 13Problemas TradicionaisDeslizes no cronograma: o dia da entrega chega e é necessário dizer ao cliente que precisará de mais 6 meses

14. Projeto cancelado: depois de vários deslizes, o projeto é cancelado sem ter chegado na fase de produção

15. O sistema “azeda”: depois de um tempo em produção o custo para modificar e a taxa de erros crescem tanto que é preciso substituir14Problemas TradicionaisTaxa de erros: o software é colocado em uso mas a taxa de erros é tão alta que ele não é usado

16. Negócio mal compreendido: o software não resolve o problema original

17. Modificações nos negócios: negócios urgentes precisam ser desenvolvidos15Problemas TradicionaisFalsa riqueza de funções: o software tem várias funções potencialmente interessantes, mas que não essenciais

18. Rotatividade da equipe: após alguns anos (cerca de 2 anos), todos os bons programadores do projeto começam a “odiar” o sistema e vão embora16Problemas Tradicionais - ConsequênciasAtrasos

19. Orçamentos estourados

20. Descontentamento dos clientes

21. Desenvolvedores trabalham longas horas

22. Uns culpam os outros

23. Descontentamento da equipe

24. Migração freqüente para outros ambientes de trabalho

25. Usuário/cliente não quer participar pois desconhece o trabalho de desenvolvimento de softwareConstrução da equipe do projeto??Mapeamento das CompetênciasPRÁTICASDE GESTÃO???

29. Uma experiência positiva de gestãoPense um momento em que você viveu uma experiência de gestão tão sintonizada com os desafios do seu papel na Empresa... num patamar tão sincronizado com a estratégia e com as pessoas ... que você ficou especialmente orgulhoso(a) e com um sentimento de “missão cumprida” !•Como foi essa experiência?•Escreva resumidamente...Compartilhe a experiência.NARRADOR DA HISTÓRIA e OUVINTE•Qual foi a “entrega”... ? E que ELEMENTOS foram importantes ou impactaram as partesinteressadas/envolvidas... (CONHECIMENTOS, HABILIDADES TECNICAS, HABILIDADES INTERPESSOAIS, ATITUDES (VALORES, CRENCAS, VISAO DE MUNDO) , ASPECTOS DO CONTEXTO... ?

31. 23Engenharia da Web “A engenharia da web diz respeito ao estabelecimento e uso de princípios científicos sólidos, de engenharia e de gestão, e abordagens disciplinadas e sistemáticas para o bem-sucedido desenvolvimento, disposição e manutenção de sistemas e aplicações de alta qualidade baseados na web”Murugesan (apud Pressman)

32. 24PodemosutilizarnaEngenharia Web osmétodos e técnicasdaEngenharia de Software tradicional?Não, a Engenhariada Web não é um clone daEngenharia de Software tradicional, emboraenvolvaprogramação e processos de desenvolvimentos.

33. 25Engenharia Tradicional X Engenharia da WebPossuempropósitosDiferentesAplicaçõesconvencionaistipicamenteoferecemserviços e soluçõesWeb oferecemconteúdosquesãoinformações, serviços…Um novo meio de comunicaçãoApresentação x FuncionalidadeAplicações: ênfasenafuncionalidade e aplicabilidadeWeb: possuiênfasenaapresentação, aparência, navegação e outrasqualidadesestéticas

34. 26Engenharia Tradicional X Engenharia da WebTradição X experiênciaEvolução Tecnológica Para softwares convencionais estão um pouco mais estáveisAPIs para interfaces gráficasBanco de dados mais relacionais com sqlBrowser, Servidores, HTML, XML, ASP, PHP, ....

35. 27Engenharia Tradicional X Engenharia da WebPúblico alvo diferenciado (exigências e perfis diferentes)Diferentes controles navegacionaisMultidisciplaridade (EW)Engenharia de software, Hipermídia e Multimídia, Interaçãousuário-computador, indexação e recuperação de informação, banco de dados, artes, comunicação visual, linguísticacomputacional, gerência de projeto, projeto e apresentaçãográfica, computaçãográfica ….

36. Engenharia da Web – Atributos de WebAppsConcentração em redes

37. WebApps estão disponíveis em redes

38. Internet: permitindo comunicação aberta ao mundo todo

39. Intranet: implementando as comunicações dentro das organizações

40. Extranet: comunicação entre redes

41. necessita atender às necessidades de uma comunidade diversificada de clientes28

42. 29Engenharia da Web – Atributos de WebAppsImpulsionadas pelo conteúdo

43. em muitos casos, a função primordial de um sistema baseado na Web é usar a hipermídia para apresentar conteúdo de texto, gráficos, áudio e vídeo ao usuário finalEngenharia da Web – Atributos de WebAppsEvolução contínua

44. ao contrário dos softwares tradicionais que evoluem ao longo de uma série de versões planejadas e cronologicamente espaçadas, aplicações baseadas na Web evoluem continuamente 30

45. 31Engenharia da Web - CaracterísticasImediatismo

46. prazo de colocação no mercado é curto

47. Estética

48. para vender idéia ou produto a apresentação é aspecto que influencia no sucesso da aplicaçãoEngenharia da Web - SegurançaSegurança

49. disponível em redes

50. limitar a população de usuário que podem ter acesso a WebApp

51. proteger conteúdo reservado

52. fornecer modos seguros de transmissão de dados32

53. 33Engenharia da Web Categorias de WebApps Informacional - Conteúdo apenas para leitura - navegação simples e links.

54. Download - Download de informações dos servidores apropriados.

55. Personalizável - Personaliza o conteúdo para suas necessidades específicas.

56. Interação - Salas de bate-papo, fóruns ou mensagens instantâneas.

57. Entrada de Usuário - Entradas baseadas em formulários.

58. Orientado a transações - O usuário faz um pedido que é atendido pelo aplicativo.Orientado a serviços - O aplicativo fornece um serviço para o usuário. Portal. O aplicativo direciona o usuário para outros conteúdos ou serviços fora do domínio do portal do aplicativo. Acesso a Banco de Dados. O usuário faz uma consulta em um banco de dados e extrai informações. Data warehousing. O usuário consulta uma coleção de grandes bancos de dados e extrai informações.34Engenharia da Web Categorias de WebApps

59. 35Engenharia da Web “O desenvolvimento Web está na adolescência... Como a maioria dos adolescentes, quer ser aceito como adulto quando tenta se afastar de seus pais. Se estiver caminhando para atingir todo o seu potencial, precisa aprender algumas lições do mundo mais maduro de desenvolvimento de software.”Doug Wallace

60. 36Engenharia da WebWebApps entregues incrementalmenteModificações ocorrem freqüentementeCronogramas são curtos

61. 37Engenharia da Web – Piores práticasTemos uma grande idéia, vamos começar a construir a WebApp agora.As coisas vão mudar constantemente, assim não tem sentido tentar entender os requisitos da WebApp.

62. 38Engenharia da Web – Piores práticasDesenvolvedores cuja experiência dominante tenha sido em desenvolvimento de software tradicional podem desenvolver WebApp imediatamenteNenhum treinamento novo é necessárioAfinal de contas software é software, não é?

63. 39Engenharia da Web – Piores práticasSeja burocráticoTestar? Por que se incomodar?Siga o mesmo processo para qualquer WebApp

64. 40Engenharia da WebAplicações baseadas na web desenvolvidas inadequadamente tem probabilidade muito alta de falha

65. Há necessidade premente de abordagens disciplinadas para desenvolvimento

66. Novos métodos e ferramentas

67. Deve levar em conta características especiais do ambiente e a multiplicidade de perfis de usuários41Engenharia da WebNos primeiros dias da www (1990 – 1995) os sites eram formados de pouco mais do que um conjunto de arquivos de hipertexto ligados que apresentavam informação usando texto e um pouco de gráficos

68. Hoje WebApps evoluíram para ferramentas computacionais sofisticadas que além de apresentar conteúdo são integradas a bancos de dados 42Engenharia da WebAplicações Web (WebApps), envolvem um mistura de:

69. publicação impressa e desenvolvimento de software

70. comercialização e computação

71. comunicações internas e relações externas

72. arte e tecnologia43Engenharia da Web Atributos de WebAppsConcentradas em Redes

73. WebApps estão disponíveis em redes

74. Internet: permitindo comunicação aberta ao mundo todo

75. Intranet: implementando as comunicações dentro das organizações

76. necessita atender às necessidades de uma comunidade diversificada de clientes44Engenharia da Web Atributos de WebAppsVoltada a dados

77. em muitos casos, a função primordial de um sistema baseado na Web é usar a hipermídia para apresentar conteúdo de texto, gráficos, áudio e vídeo ao usuário final.45Engenharia da WebAtributos de WebAppsConcorrência

78. Um grande número de usuários pode ter acesso à WebApp ao mesmo tempo

79. Carga imprevisível

80. Vários usuários acessando ao mesmo tempo. Cem usuários podem “aparecer” na segunda-feira; dez mil podem usar o sistema na terça-feira46Engenharia da Web Atributos de WebAppsDesempenho

81. Se um usuário da WebApp tem de esperar muito (acesso, processamento, exibição) ele vai para outro lugar

82. Disponibilidade

83. Os usuários querem acesso na base de “24/7/365”47Engenharia da Web Atributos de WebAppsEvolução contínua

84. ao contrário dos softwares tradicionais que evoluem ao longo de uma série de versões planejadas e cronologicamente espaçadas, aplicações baseadas na Web evoluem continuamente Camadas da Engenharia de SoftwareCamadas da Engenharia de Software (Pressman)FerramentasMétodosProcessosFoco na qualidade48

85. Camadas da Engenharia de SoftwareDesenvolver software de qualquer natureza exige organização, dedicação, estrutura

86. É necessário coordenar o que e quando fazer

87. Programação é somente parte do trabalho49

88. 50Camadas da Engenharia da WebProcesso

89. Abordagem de desenvolvimento simples que incorpora ciclos rápidos de desenvolvimento

90. Modificação da prioridade do o quê? Para quando?

91. o problema deve ser analisado, o projeto deve ser desenvolvido, implementação deve ser procedida de modo incremental e uma abordagem organizada de testes deve ser realizadaFalando em testes - Princípios básicos para o teste de software - WebApps Pressman (2006) apresenta uma abordagem que adota os princípios básicos para o teste de todo software, aplica estratégias e táticas que são recomendadas para sistemas OO. Revisar o conteúdo a fim de descobrir erros de grafia, gramática, consistência do conteúdo, representações gráficas, dentre outros;Revisar o projeto de navegação para descobrir erros nos links e/ou na permissão de acesso de cada usuário;testar cada página focando seu processamento;Testar a funcionalidade geral e conteúdo fornecido;Testar a compatibilidade da aplicação em diferentes configurações diferentes browsers, sistemas operacionais, plataformas de hardware e protocolos de comunicação. 51

92. 52Camadas da Engenharia da WebProcesso - atividades

93. Acolher modificações

94. Encorajar a criatividade e independência da equipe de desenvolvimento

95. Forte interação com os interessados nas WebApps

96. Pequenas equipes

97. Enfatizar o desenvolvimento evolutivo ou incremental usando ciclos de desenvolvimento curtos53Camadas da Engenharia da WebMétodos

98. Métodos de comunicação: facilitar a comunicação entre equipe e interessados; usados em cada incremento.

99. Métodos de análise de requisitos: fornecer base para o entendimento do conteúdo a ser entregue.54Camadas da Engenharia da WebMétodos

100. Métodos de projeto: projetar conteúdo, arquitetura, interface e estrutura de navegação

101. Métodos de teste: incorporar revisões técnicas formais do conteúdo e projeto, teste de navegação, teste de segurança, teste de usabilidade, teste de configuração55Camadas da Engenharia da WebFerramentas e Tecnologia

102. Linguagens de modelagem (HTML, XML)

103. Linguagens de programação (Java, php)

104. Componentes (.NET, COM, CORBA)

105. Navegadores

106. Ferramentas multimídia

107. Ferramentas de autoria de sites

108. Ferramentas de conectividade com BD

109. Ferramentas de segurança

110. Gestão e análise de sites56Camadas da Engenharia da WebFerramentas e Tecnologia

111. Web Developer´s Virtual Encyclopedia (www.wdlv.com)

112. WebDeveloper (www.webdeveloper.com)

113. DeveloperShed (www.devshed.com)

114. Webnowhow.net (www.webnowhow.com)

115. WebReference (www.webreference.com)Modelo de processo da WebE57(Pressman, 2002)

116. Modelo de processo da WebE58Iterativo e incremental

117. Formulação

118. identificação das metas e dos objetivos da WebApp

119. qual é a principal motivação da WebApp?

120. por que a WebApp é necessária?

121. quem vai usar a WebApp?

122. estabelece o escopo do primeiro incrementoModelo de processo da WebE59Planejamento

123. estima-se o custo global do projeto

124. avaliação dos riscos

125. definição de cronograma detalhado para o primeiro incremento

126. previsão de cronograma para os incrementos subsequentesModelo de processo da WebE60Análise

127. estabelecimento dos requisitos

128. identificação do conteúdo

129. definição do projeto gráfico (estética)

130. documentação X evolução contínua: como conciliar?

131. Modelo de processo da WebE61Engenharia

132. Projeto do conteúdo e produção: projetar e/ou adquirir todo o conteúdo de texto, gráfico, áudio e vídeo, que deve ser integrado na WebApp estas tarefas são desenvolvidas pelos membros "não-técnicos" da equipe.

133. Projeto arquitetural: focaliza a estrutura global de hipermídiaModelo de processo da WebE62Engenharia

134. Projeto navegacional

135. definição dos caminhos de navegação que permitem ao usuário ter acesso ao conteúdo e aos serviços

136. pode estar ligado ao tipo de usuário

137. definição da mecânica da navegação: ligações baseadas em texto, ícones, botões

138. estabelecer convenções e ajudas à navegação63Modelo de processo da WebEEngenharia

139. Projeto da interface

140. “Primeira impressão”

141. Uma interface bem projetada melhora a percepção do usuário em relação ao conteúdo ou os serviços fornecidos

142. Bem estruturada e ergonomicamente sólida

143. Uma interface mal projetada vai desapontar o usuário e pode provocar sua ida para outra aplicaçãoModelo de processo da WebE64Geração de página

144. o conteúdo produzido na engenharia é combinado com o projeto arquitetural, navegacional e de interface para produzir páginas da web executáveis, utilizando uma linguagem de programação

145. Teste

146. exercita a navegação da WebApp

147. tenta descobrir erros

148. ajuda garantir a correta operaçãoModelo de processo da WebE65Avaliação do Cliente

149. revisão dos incrementos produzidos

150. solicitação de modificações

151. as modificações são integradas nos próximos incrementosplanejamentocomunicaçãomodelageminícioAtividades guarda-chuvaincrementoentregaconstruçãoFonte: Pressman 200666Processo Genérico da ES da Web

152. Equipe da WebE67Desenvolvedores e provedores de conteúdo

153. geração ou coleta do conteúdo

154. oriundos de diversas áreas: venda ou comercialização, produtores de áudio e vídeo, redatores, projetistas gráficos, pessoal de pesquisa

155. Editor da web

156. organizar o conteúdo

157. precisa conhecer tanto do conteúdo quanto da tecnologiaEquipe da WebE68Engenheiro da web

158. dedução de necessidades

159. análise e modelagem

160. projeto arquitetural, navegacional e de interface

161. implementação e teste

162. sólidos conhecimentos de:

163. arquiteturas cliente/servidor

164. HTML/XML e tecnologias de bancos de dados

165. multimídia

166. plataformas de hardware/software, segurança de redes.Equipe da WebE69Especialista no domínio do negócio

167. capaz de responder a todas as questões relativas às metas, aos objetivos e aos requisitos de negócio associados a WebApp

168. Especialista de suporte

169. dar continuidade ao suporte da WebApp

170. correções, adaptações, aperfeiçoamento

171. atualizações de conteúdo

172. implementação de novos procedimentos e formulários

173. modificações no padrão de navegação70Equipe da WebEAdministrador (Web Master)

174. desenvolvimento e implementação de políticas de operação da WebApp

175. estabelecimento de procedimentos de suporte e realimentação

176. implementação de procedimentos de segurança e direitos de acesso

177. medição e análise do tráfego no site Web

178. coordenação dos procedimentos de controle de modificações

179. coordenação dos especialistas de suporteConstrução da Equipe71Estabelecer um conjunto de diretrizes para a equipe

180. Forte liderança é uma necessidade

181. Respeitar os talentos individuais é crítico

182. Todos os membros da equipe devem estar comprometidos

183. É fácil iniciar, mas é muito difícil manter o ritmoMelhores práticas72Empregue tempo para entender as necessidades do negócio e os objetivos do produto, mesmo se os detalhes da WebApp forem vagos

184. Desenvolva um plano de projeto, mesmo que seja abreviado

185. Empregue tempo modelando o que você está querendo construir

186. Revise os modelos quanto a consistência e qualidadeMelhores práticas73Use ferramentas e tecnologia que possibilitem construir o sistema com tantos componentes reusáveis quanto possível

187. Não confie nos primeiros usuários para depurar a WebApp – projete testes abrangentes e execute-os antes de entregar o sistema74Melhores práticasExistemváriasfontes de pesquisasobreWebE. Um bomponto de partida: http://www.rspa.com/spi/index.html

188. Qualidade na Web75(Olsina, 99)

189. 76Qualidade na Web (Offut 2002)Segurança

190. Disponibilidade

191. Escalabilidade

192. Prazo de colocação no mercadoDiretrizes de projetos de interface WebApp(Nielsen e Wagner)77Precisa “prender” um provável usuário imediatamente

193. Não forçar um usuário a ler quantidades volumosas de texto, particularmente quando o texto explica a operação da WebApp ou apóia a navegação

194. Evitar sinais de “em construção” – eles levam a expectativas e causam um link desnecessário que vai certamente desapontar78Diretrizes de projetos de interface WebApp(Nielsen e Wagner)Usuário prefere não rolar: uma informação importante deve ser colocada dentro das dimensões da janela

195. a estética nunca deve superar a funcionalidade. Ex.: melhor um botão simples do que uma imagem vaga.

196. as opções de navegação devem ser óbvias

197. o projetonãodeve se apoiarnasfunções do navegadorparaajudarnanavegação79Processos de desenvolvimento de software tradicionaisCascataPrototipação Incremental Espiral Baseado em ComponentesProcesso Unificado e RUP

198. 80Processos de desenvolvimento de software – Métodos ÁgeisXP (Extreme Programming)SCRUM FDD (Feature Driven Development)DSDM (Dynamic System Development Method)ASD (Adaptative Software Development)ModelagemÁgilCrystal

199. IRUP – I (BM) RationalUnifiedProcesshttp://www.wthreex.com/rup/portugues/tour/tour.htm

200. RUP – RationalUnifiedProcessDirigido por casos de uso: casos de uso são utilizados como o principal artefato para o estabelecimento do comportamento desejado do sistema, para a verificação e para a comunicação entre os participantes do projeto

201. Centrado na arquitetura: pensa-se primeiro nos elementos de desempenho, escalabilidade, reutilização, restrições econômicas e tecnológicas, começando pela “visão” do software82

202. Iterativo: envolve o gerenciamento de seqüências de versões executáveis

203. Incremental: envolve a integração contínua da arquitetura do sistema para a produção das versões, de maneira que cada versão incorpore os aprimoramentos incrementais em relação às demais83RUP – RationalUnifiedProcess

204. 84VantagensOs profissionais são forçados a atacar a parte mais crítica do software logo no início. Os custos e os prazos são definidos na fase inicial do projeto.Desta forma, os riscos do software são conhecidos pelo desenvolvedor. Faz-se uso de iterações para evitar o impacto de mudanças no projeto e o gerenciamento de mudanças ao longo do desenvolvimento. A aplicação do RUP torna o processo flexível, permitindo reavaliações e readequações.

205. 85ProblemasRelativamente novo.Modelo complexo, não se aplicando às situações que não apresentam tal complexidade. As fases nem sempre são adequadas software que está sendo desenvolvido apresenta requisitos muito dinâmicos ou seja, que se alteram freqüentemente.

206. 86

207. 87Manifesto ÁgilMovimento iniciado por um grupo de programadores experientes e consultores em métodos de desenvolvimento de software “leves”

208. Criado em 2001, autodenominado como aliança ágil (agilealliance.org)88Manifesto ÁgilValoriza um conjunto de valores e práticas ágeis para o desenvolvimento de software mais eficaz

209. Defende valores que devem ser executados com a finalidade de obter um processo mais iterativo e menos burocrático 89Motivação dos ÁgeisÉ difícil predizer quais requisitos serão mantidos e quais vão mudar, assim como quais prioridades mudarão

210. É difícil saber quanto projeto é suficiente para começar. Projeto e implementação são feitos em paralelo

211. Análise, projeto, construção e teste não são tão previsíveis (do ponto de vista de planejamento) como gostaríamos90O que é um Processo Ágil?O processo deve gerenciar o imprevisível

212. Não pode só se adaptar sem progredir

213. Para ter adaptabilidade incremental é necessário feedback do cliente91Perfil da Equipe Competência

214. talento nato

215. habilidades específicas de desenvolvimento de software

216. conhecimento do processo a ser usado

217. Foco comum

218. entregar ao cliente a próxima versão (incremento) do sistema no prazo prometido92Perfil da Equipe Colaboração

219. entre si e com o cliente

220. Autonomia

221. autoridade para tomar decisões técnicas e de planejamento

222. Versatilidade

223. aceitar o fato de que o problema sendo resolvido hoje pode mudar amanhã93Perfil da Equipe Respeito e confiança mútuos

224. o conjunto é maior do que a soma das partes

225. Auto-organização

226. o time se auto-gerencia com relação ao trabalho a ser feito, às adaptações ao processo e ao calendário94Princípios ÁgeisIndivíduos e iterações têm mais importância do que processos e ferramentas

227. O software funcionando é mais importante do que uma vasta documentação95Princípios ÁgeisA colaboração do cliente é mais importante do que a negociação de contratos

228. Adaptação a mudanças é mais importante do que seguir um plano96Princípios ÁgeisMaior prioridade na satisfação do cliente, entregando software com valor e em tempo hábil

229. Preparar-se quanto às mudanças de requisitos, mesmo que elas apareçam na fase mais avançada do desenvolvimento97Princípios ÁgeisEntregar versões funcionais com freqüência e de preferência no menor espaço de tempo

230. As equipes devem trabalhar juntas durante todo o projeto98Princípios ÁgeisConstruir projetos com pessoas motivadas, confiando nelas e fornecendo um ambiente de trabalho apropriado

231. As conversas diretas atuam como uma forma eficiente de trocar informações e fazê-las funcionar99Princípios ÁgeisO software funcionando é a principal forma de medir o progresso

232. Os processos ágeis geram um desenvolvimento sustentável

233. Atenção contínua ao nível técnico e um bom projeto aumentam a agilidade100Princípios ÁgeisA simplicidade é essencial

234. Melhores arquiteturas, requisitos e projetos são provenientes de equipes organizadas

235. De tempo em tempo a equipe reflete sobre como se tornar mais eficaz, ajustando o seu comportamento101Ágeis X TradicionaisAgilistas:“Os engenheiros tradicionais preferem produzir uma documentação impecável do que um software que funcione e atenda ao cliente.”Tradicionalistas: “Engenheiros ágeis terão uma bela surpresa quando tentarem usar seus brinquedinhos em sistemas grandes e complexos.”

236. 102Ágeis X TradicionaisNada se ganha com “guerras religiosas”

237. Muito se ganha em considerar o melhor de cada abordagem

238. Métodos ágeis não são a antítese dos métodos tradicionais

239. Agilidade pode ser aplicada a qualquer processo de softwareMODELO ESTRELA: UM MODELO DE PROCESSO PARA DESENVOLVIMENTO DE SISTEMAS WEB USANDO AS MELHORES PRÁTICAS TRADICIONAIS E ÁGEIS

240. Modelo EstrelaObjetivos Orientar o processo de desenvolvimento de sistemas web, através de:Gerenciamento de projetos;Gerenciamento de riscos;Vantagens dos métodos ágeis e tradicionais.104

241. Origem do nome ESTRELA105

242. Características do modelo ESTRELA106Indivíduos possuem forte ligação com as iterações;Documentação adequada (propostas e contratos);Adaptação a mudanças;Versão funcional em menos espaço de tempo;Comunicação constante;Padronização .

243. Características do modelo ESTRELA107Conversas diretas são eficientes;

244. O software funcionando e a satisfação do cliente são as principais formas de medir o progresso;

245. Os estágios podem ser realimentados;

246. Gerenciado – 9 áreas do PMI;

247. Controle e monitoração dos Riscos – MODELO E-RISCOS (PMI, RUP, ESPIRAL, prototipação e FDD);Papéis 108Avaliador; Cliente;Cliente final;Desenvolvedor;Designer;Gerente de projetos;Gerente de equipe;Representante comercial;Gerente empresarial (proprietário).

248. Estágios do modelo ESTRELA109

249. Estágios do modelo ESTRELAPré-aquisição110A pré-aquisição possui 3 subestágios:Definição de requisitos preliminares (linguagem natural não detalhada); Elaboração da proposta;Projeto de interface (layout).Envolvidos:Cliente;Representante comercial;Gerente de projetos e de equipe;Designer.

250. Gerenciamento de projetos ..111MODELO E-RISCOS (...)Gerenciamento de riscos: E-RISCOSIdentificação, Priorização, Planejamento, Administração, Padronização e reação dos riscos. Esse assunto será melhor apresentado posteriormente...Cronogramas, prazos, custos, riscos, metas, objetivos, prioridades e distribuição das tarefas entre a equipe.Envolvidos:Cliente;Representante comercial;Gerente de projetos;Gerente de equipe;Gerente empresarial;Desenvolvedores.

251. Aquisição112Detalha-se os principais requisitos (funcionais e não funcionais)Subestágios:Definição de requisitos fundamentais – identificar e priorizar os elementos de maior risco para o projeto;Formalização da proposta – contrato.

252. Definição de requisitos complementaresAcomoda os requisitos dinâmicos (evolução do software)Está presente no centro do modelo e possui ligação com estágio de Planejamento e gerenciamento.Subestágios:Definição de requisitos fundamentais – identificar e priorizar os elementos de maior risco para o projeto;Formalização da proposta – contrato;Documentos:Aditivo contratualEnvolvidos:É conduzido pelo Gerente de projetos e de equipe;Representante comercial;Demais desenvolvedores.113

253. DesenvolvimentoImplementação dos requisitos;Subestágios:Concepção do projeto Desenvolvimento em pares;Identificação das áreas críticas e grau de dificuldade.Padrão de desenvolvimento;Modelo de dados (análise - estrutura e comportamento esperado);Modelo funcional (entradas, manutenções, consultas, relatórios, etc).ImplementaçãoDetalhamento do projeto navegacional e de interface realizando também se necessário ajustes no protótipo;Saída:Pelo menos uma funcionalidade.Envolvidos:Desenvolvedores;Gerente de projetos e de equipe;Cliente;Representante comercial.114

254. Verificação dinâmicaValidar os requisitos através de testes (que podem ser chamados em qualquer fase)Saída:Documento com o parecer da avaliação.Retorna ao desenvolvimento até que esteja atenda os requisitos especificados.Envolvidos:Avaliador;Desenvolvedor;Gerente de projetos e de equipe.115

255. Entrega iterativaO cliente executa, testa e navega nas partes executáveis do software;Encerramento do projeto (quando todos requisitos são atendidos).Saída:Realizado através de ftp dos arquivos (módulos)Documento com o parecer da avaliação (favorável, restrição...) e-mail, fax, sistema próprio ...)Envolvidos:Gerente de projetos;Desenvolvedores;Cliente.116