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.br marcia@imed.edu.br

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

5. agregar experiências,

7. 6 E agora ?

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

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

11. PROCESSO DE GESTÃO DA MUDANÇA Comunicação em duas vias Suporte técnico Celebração Treinamento envolvimento Comunicação em duas vias Informação “Eu faço” “Eu posso” “Eu acredito” “Eu entendo” SAP “EU sei”

12. Relação com as demais disciplinas Engenharia de software (Trad. e Web) Requisitos de software Gerenciamento de projetos Projetos de Desenvolvimento Riscos de Projetos

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

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

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

29. Uma experiência positiva de gestão Pense 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 partes interessadas/envolvidas... (CONHECIMENTOS, HABILIDADES TECNICAS, HABILIDADES INTERPESSOAIS, ATITUDES (VALORES, CRENCAS, VISAO DE MUNDO) , ASPECTOS DO CONTEXTO... ?

31. 23 Engenharia 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. 24 PodemosutilizarnaEngenharia 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. 25 Engenharia Tradicional X Engenharia da Web PossuempropósitosDiferentes Aplicaçõesconvencionaistipicamenteoferecemserviços e soluções Web oferecemconteúdosquesãoinformações, serviços… Um novo meio de comunicação Apresentação x Funcionalidade Aplicações: ênfasenafuncionalidade e aplicabilidade Web: possuiênfasenaapresentação, aparência, navegação e outrasqualidadesestéticas

34. 26 Engenharia Tradicional X Engenharia da Web Tradição X experiência Evolução Tecnológica Para softwares convencionais estão um pouco mais estáveis APIs para interfaces gráficas Banco de dados mais relacionais com sql Browser, Servidores, HTML, XML, ASP, PHP, ....

35. 27 Engenharia Tradicional X Engenharia da Web Público alvo diferenciado (exigências e perfis diferentes) Diferentes controles navegacionais Multidisciplaridade (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 ….

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

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

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

47. Estética

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

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.

59. 35 Engenharia 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. 36 Engenharia da Web WebApps entregues incrementalmente Modificações ocorrem freqüentemente Cronogramas são curtos

61. 37 Engenharia da Web – Piores práticas Temos 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. 38 Engenharia da Web – Piores práticas Desenvolvedores cuja experiência dominante tenha sido em desenvolvimento de software tradicional podem desenvolver WebApp imediatamente Nenhum treinamento novo é necessário Afinal de contas software é software, não é?

63. 39 Engenharia da Web – Piores práticas Seja burocrático Testar? Por que se incomodar? Siga o mesmo processo para qualquer WebApp

65. Há necessidade premente de abordagens disciplinadas para desenvolvimento

66. Novos métodos e ferramentas

69. publicação impressa e desenvolvimento de software

70. comercialização e computação

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

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

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

79. Carga imprevisível

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

82. Disponibilidade

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

87. Programação é somente parte do trabalho49

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

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

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

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

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

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

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)

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?

123. estima-se o custo global do projeto

124. avaliação dos riscos

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

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?

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.

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

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

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

149. revisão dos incrementos produzidos

150. solicitação de modificações

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

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

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

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

180. Forte liderança é uma necessidade

181. Respeitar os talentos individuais é crítico

182. Todos os membros da equipe devem estar comprometidos

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

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

188. Qualidade na Web 75 (Olsina, 99)

190. Disponibilidade

191. Escalabilidade

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

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

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

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

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

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 demais83 RUP – RationalUnifiedProcess

204. 84 Vantagens Os 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. 85 Problemas Relativamente 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

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

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

214. talento nato

215. habilidades específicas de desenvolvimento de software

216. conhecimento do processo a ser usado

217. Foco comum

219. entre si e com o cliente

220. Autonomia

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

222. Versatilidade

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

225. Auto-organização

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

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

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

240. Modelo Estrela Objetivos 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 ESTRELA 105

242. Características do modelo ESTRELA 106 Indiví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 .

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;

248. Estágios do modelo ESTRELA 109

249. Estágios do modelo ESTRELAPré-aquisição 110 A 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 .. 111 MODELO E-RISCOS (...) Gerenciamento de riscos: E-RISCOS Identificaçã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ção 112 Detalha-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 complementares Acomoda 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 contratual Envolvidos: É conduzido pelo Gerente de projetos e de equipe; Representante comercial; Demais desenvolvedores. 113

253. Desenvolvimento Implementaçã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ção Detalhamento 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âmica Validar 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 iterativa O 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