Tópicos Avançados de Engenharia de Software

MDULO DE:
TPICOS AVANADOS de ENGENHARIA de SOFTWARE
AUTORIA:
Ms. Carlos Valente
Copyright 2008, ESAB Escola Superior Aberta do Brasil
Mdulo de: TPICOS AVANADOS de ENGENHARIA de SISTEMAS Autoria: Ms. Carlos Valente
Primeira edio: 2008
Todos os direitos desta edio reservados ESAB ESCOLA SUPERIOR ABERTA DO BRASIL LTDA http://www.esab.edu.br Av. Santa Leopoldina, n 840/07 Bairro Itaparica Vila Velha, ES CEP: 29102-040 Copyright 2008, ESAB Escola Superior Aberta do Brasil
presentao
A Engenharia de Sistemas ainda continua em plena expanso e a cada dia apresenta novas tcnicas e recursos. A Engenharia de Software como seu principal expoente apresenta tpicos especiais dos quais o profissional da rea precisa para estar sempre atualizado.
bjetivo
Apresentar tpicos mais avanados de Engenharia de Software, conforme o SWEBOK, destacando aqueles mais atuais ou com tendncias para o futuro. Destacar a parte de segurana, qualidade, gerenciamento de pessoal tcnico e sistemas para a Web
menta
SWEBOK, Estilos Arquiteturais, Engenharia de Proteo, Interface com Usurio, Gesto de Pessoal, ISO 9001, Sistemas Crticos, Arquiteturas tolerantes a falhas, Estratgias de Teste de Software, Softwares de Tempo Real, Engenharia de Servios, Estimativa de custo de Software, Mtricas para pequenas Organizaes, COCOMO II, Engenharia de Software para a WEB, Ferramentas de Gesto de Projetos para a WEB
obre o Autor
Professor e Consultor de Tecnologia de Informao
Doutorando (ITA) e Mestre (IPT) em Engenharia de Computao, Ps-Graduado em Anlise de Sistemas (Mackenzie), Administrao (Luzwell-SP), e Reengenharia (FGVSP). Graduado/Licenciado em Matemtica.
Professor e Pesquisador da Universidade Anhembi Morumbi, UNIBAN, e ESAB (Ensino a Distncia). Autor de livros em Conectividade Empresarial. Prmio em ELearning no Ensino Superior (ABED/Blackboard).
Consultor de T.I. em grandes empresas como Sebrae, Senac, Granero, Transvalor, etc. Viagens internacionais: EUA, Frana, Inglaterra, Itlia, Portugal, Espanha, etc.
UMRIO
UNIDADE 1 ......................................................................................................................................... 7 Swebok Software Engineering Body Of Knowledge ...................................................................... 7 UNIDADE 2 ....................................................................................................................................... 14 Taxonomia De Estilos Arquiteturais ............................................................................................... 14 UNIDADE 3 ....................................................................................................................................... 19 Engenharia De Proteo ................................................................................................................ 19 UNIDADE 4 ....................................................................................................................................... 23 Diretrizes Para Um Projeto Seguro ................................................................................................ 23 UNIDADE 5 ....................................................................................................................................... 28 Projeto De Interface Com O Usurio .............................................................................................. 28 UNIDADE 6 ....................................................................................................................................... 34 Gerenciamento De Pessoal ........................................................................................................... 34 UNIDADE 7 ....................................................................................................................................... 38 Modelos De Gerenciamento De Pessoal........................................................................................ 38 UNIDADE 8 ....................................................................................................................................... 42 Gerenciamento De Qualidade ........................................................................................................ 42 UNIDADE 9 ....................................................................................................................................... 47 Padro De Qualidade - Iso 9001 .................................................................................................... 47 UNIDADE 10 ..................................................................................................................................... 51 Desenvolvimento De Sistemas Crticos.......................................................................................... 51 UNIDADE 11 ..................................................................................................................................... 55 Desenvolvimento De Sistemas Crticos (Continuao)................................................................... 55 UNIDADE 12 ..................................................................................................................................... 58 Arquiteturas Tolerantes A Defeitos................................................................................................. 58 UNIDADE 13 ..................................................................................................................................... 62 Estratgias De Teste De Software ................................................................................................. 62 UNIDADE 14 ..................................................................................................................................... 65 Espiral Dos Testes De Software..................................................................................................... 65 UNIDADE 15 ..................................................................................................................................... 68
5
Testes Caixa-Preta E Caixa-Branca ............................................................................................... 68 UNIDADE 16 ..................................................................................................................................... 72 Mtodos De Teste Orientado A Objetos ......................................................................................... 72 UNIDADE 17 ..................................................................................................................................... 75 Projeto De Software De Tempo Real ............................................................................................. 75 UNIDADE 18 ..................................................................................................................................... 80 Engenharia De Software Orientada A Servios .............................................................................. 80 UNIDADE 19 ..................................................................................................................................... 84 Engenharia De Servios................................................................................................................. 84 UNIDADE 20 ..................................................................................................................................... 89 Desenvolvimento De Software Orientado A Aspectos .................................................................... 89 UNIDADE 21 ..................................................................................................................................... 93 Engenharia De Software Com Aspectos ........................................................................................ 93 UNIDADE 22 ..................................................................................................................................... 96 Estimativa De Custo De Software .................................................................................................. 96 UNIDADE 23 ................................................................................................................................... 100 Mtricas Para Pequenas Organizaes ....................................................................................... 100 UNIDADE 24 ................................................................................................................................... 105 Estimativa Do Projeto De Software .............................................................................................. 105 UNIDADE 25 ................................................................................................................................... 109 Modelo De Estimativa De Software Cocomo Ii .......................................................................... 109 UNIDADE 26 ................................................................................................................................... 113 Engenharia De Software Para A Web .......................................................................................... 113 UNIDADE 27 ................................................................................................................................... 119 Engenharia De Software Para A Web Metodologia ................................................................... 119 UNIDADE 28 ................................................................................................................................... 122 Engenharia De Software Para A Web Oohdm........................................................................... 122 UNIDADE 29 ................................................................................................................................... 127 Planejamento Da Webapp ........................................................................................................... 127 UNIDADE 30 ................................................................................................................................... 130 Ferramentas De Software Para Gesto De Projetos Web ............................................................ 130 GLOSSRIO ................................................................................................................................... 135 REFERNCIAS ............................................................................................................................... 136
6
NIDADE
Swebok Software Engineering Body Of Knowledge Objetivo: Destacar a importncia e as principais divises que o SWEBOK apresenta quanto Engenharia de Software. provvel que o projeto SWEBOK torne-se to importante dentro da rea de Tecnologia da Informao quanto o PMBOK dentro da rea de Gerncia de Projetos. Seus padres se transformaro em guias para o profissional de Tecnologia da informao. At ltima verso do SWEBOK, verso 2004, houve a participao de nove pesquisadores brasileiros na sua elaborao. E em seu painel de especialistas estavam relacionados trs profissionais renomados, dentre eles Pressman e Sommerville. Podemos definir Engenharia de Software como sendo: Engenharia de Software a uma rea de interesse (disciplina) preocupada com a criao e manuteno de aplicaes de software pela aplicao de tecnologias e prticas da cincia da computao, gerncia de projetos, engenharia, domnios de aplicao e outros campos. Mas, a Engenharia de
software uma disciplina que est em desenvolvimento e existe uma grande tendncia ao aumento no seu nvel de maturidade, mas no uma disciplina legtima de engenharia, nem uma profisso reconhecida (SWEBOK, 2004). Os principais objetivos que o SWEBOK se prope so: Promover uma viso consistente da engenharia de software no mbito mundial. Clarear e marcar as fronteiras entre a engenharia de software e as outras disciplinas relacionadas (cincia da computao, gerncia de projetos, matemtica, entre outros).
Origens do Corpo de Conhecimentos da Engenharia de Software: Caracterizar o contedo da disciplina de engenharia de software. Classificar em tpicos a rea de conhecimento da engenharia de software Prover uma base para o desenvolvimento curricular, para certificao individual e para licenciamento de material. O Swebok est dividido em partes para facilitar o entendimento e possibilitar a especializao. Cada parte chamada de rea de Conhecimento. As dez reas de conhecimento definidas so:
PRIMEIRO DESENHO
Requisitos de Software Design de Software Construo de Software Teste de Software Manuteno de Software
SEGUNDO DESENHO
Gerncia de Configurao de Software Gerncia de Engenharia de Software Processo de Engenharia de Software Mtodos e Ferramentas de Engenharia de Software
Qualidade de Software
Requisitos De Software Esta rea est relacionada com o levantamento das propriedades que o software deve possuir e as restries existentes. Ela explicita, analisa e valida os requisitos de maneira a permitir que no final do projeto o software tenha uma chance maior de atender as necessidades dos clientes. Esta rea de extrema importncia, pois ao fazer a anlise e a validao dos requisitos do software, podem ser percebidos carncia de algumas propriedades que o software deve possuir e at mesmo conflito entre as necessidades existentes, possibilitando prever problemas e propor mudanas antes do software comear a ser implementado.
Design De Software Transformao de requisitos de software, tipicamente estabelecidos em termos relevantes ao domnio do problema, em uma descrio explicando como solucionar os aspectos do problema relacionados com software.
Construo De Software Construo de programas funcionais e coerentes atravs da codificao, autovalidao, e teste unitrio.
Teste De Software Verificao dinmica do comportamento do programa atravs do uso de um conjunto finito de casos de teste adequadamente selecionados de um domnio de execues usualmente infinito - contra o comportamento esperado deste.
10
Manuteno De Software Atividades de suporte custo-efetivo a um sistema de software, que pode ocorrer antes e aps a entrega do software. Aps a entrega do software so feitas modificaes com o objetivo de corrigir falhas, melhorar seu desempenho ou adapt-lo a um ambiente modificado. Antes da entrega do software so feitas atividades de planejamento.
11
Gerncia De Configurao De Software Identifica a configurao do sistema (caractersticas documentadas do hardware e software que o compem) em pontos discretos no tempo, de modo a controlar sistematicamente suas mudanas e manter sua integridade e rastreabilidade durante o ciclo de vida do sistema.
Gerncia De Engenharia De Software Gerencia projetos de desenvolvimento de software.
Processo De Engenharia De Software Define, implementa, mede, gerencia, modifica e aperfeioa o processo de desenvolvimento de software.
Mtodos E Ferramentas De Engenharia De Software Ferramentas de software que automatizam o processo de engenharia de software. Mtodos impem estrutura sobre a atividade de desenvolvimento e manuteno de software com o objetivo de torn-la sistemtica e mais propensa ao sucesso.
Qualidade De Software A rea de qualidade software est relacionada com consideraes de qualidade de software que transcendem os processos de ciclo de vida do software. Ela est ligada diretamente com a qualidade do produto do software. Porm impossvel separar a qualidade final do produto da qualidade do processo onde o produto est sendo desenvolvido, pois o processo de
Copyright 2007, ESAB Escola Superior Aberta do Brasil 12
desenvolvimento influencia fortemente o produto final gerado e se este processo no possuir um determinado grau de qualidade o resultado final no ser satisfatrio.
http://www.swebok.org/ http://pt.wikipedia.org/wiki/Software_Engineering_Body_of_Knowledge http://www.cic.unb.br/~jhcf/MyBooks/iess/Intro/10AreasDaEngenhariaDeSoftware.pdf http://www.cin.ufpe.br/~dar/SWEBOK%20cinco%20areas%20da%20eng%20software%20-%20dar.pdf
1. Atividade 1: O BLOG do Marco Mendes realmente muito interessante !! Aproveite para visit-lo e receber mais informaes de outros BOKs existentes: http://blog.marcomendes.com/2007/08/29/swebok-pmbok-babok-outrosboks/ 2. Atividade 2: Baixe o SWEBOK atravs do link abaixo (existe a necessidade de entrar com nome e email para baixar do site oficial): http://www.swebok.org/pdfformat.html
13
NIDADE
Taxonomia De Estilos Arquiteturais Objetivo: Apresentar os estilos arquiteturais mais importantes para a Engenharia de Software. Embora tenhamos milhes de sistemas desenvolvidos ao longo do tempo podemos categoriz-los em poucos estilos arquiteturais. Conforme os estudos dos pesquisadores Swaw, M. e Garlan, D., Buschmann, F., Bass L., Clements P. e Kazman, R. chega-se basicamente em cinco estilos arquiteturais. A taxonomia definida como sendo a cincia ou tcnica de classificao. Para o nosso caso ela estrutura os vrios tipos de arquitetura existentes. Vejamos, portanto, os estilos arquiteturais mais importantes:
Arquitetura Centrada Nos Dados Nesse tipo de arquitetura, tambm chamada de Repositrio, temos o conceito de Depsito de Dados e que alguns autores intitulam tanto de Repositrio, como Blackboard (QuadroNegro). Conforme a figura a seguir, temos na rea central a Base Central de Dados (Blackboard), e os componentes que executam operaes na referida base, inclusive suas intercomunicaes. Alguns autores chamam esses componentes que acessam o repositrio central de SoftwareCliente, e outros de fontes de informao (Knowledge Source - Ks). Uma das caractersticas fortes dessa arquitetura que embora os componentes estejam interligados atravs da base, eles no podem se comunicar um com outro, exceto via repositrio central.
14
Arquitetura De Fluxo De Dados Essa estrutura tambm chamada de tubos e filtros, pois os dados de entrada devem ser transformados, por meio de uma srie de componentes computacionais, em dados de sada (Pressman, 2006). Na figura abaixo temos as linhas representando os tubos, e os retngulos como sendo os filtros. Cada filtro trabalha independentemente dos componentes afluentes e efluentes, e projetado para esperar entrada de dados de certa forma e produzir dados de sada (para o filtro seguinte) de um modo especfico.
15
Arquitetura De Chamada E Retorno Arquitetura clssica muito utilizada na anlise estruturada, e quando linguagens de programao no possuem um suporte efetivo para o encapsulamento esta a arquitetura preferencial. Esta arquitetura tambm chamada de arquitetura de programa principal/sub-rotinas caracteriza-se pela existncia de um programa inicial (programa principal) que chama diversos outros programas (sub-rotinas) em uma sequncia preestabelecida. Cada um dos programas chamados ao terminar, retorna seu controle ao programa chamador.
Arquitetura Orientada A Objetos A caracterstica principal dessa arquitetura so que os elementos de um sistema, os dados e as operaes, so encapsulados em um componente chamado objeto. A comunicao e a coordenao entre esses componentes, intitulados objetos, so obtidos por meio de passagem de mensagens.
16
Arquitetura Em Camadas Esta arquitetura representada atravs de uma figura que faz lembrar uma cebola. Na camada mais interna temos operaes mais prximas do conjunto de instrues de mquina fazendo interface com o Sistema Operacional. As camadas intermedirias fornecem servios utilitrios e funes do software de aplicao. A arquitetura em camadas possui uma caracterstica forte para reuso, e como exemplo, podemos citar o conceito de mquinas virtuais em linguagens de programao, como o Java.
17
http://pt.wikipedia.org/wiki/Arquitetura_de_software Um site dedicado a discusso das arquiteturas de sistema: http://www.softwarearchitectures.com http://www.sei.cmu.edu/architecture/published_definitions.html
Veja a interessante Dissertao de Mestrado de Marcelo Cabral da Silva com o ttulo Identificao de estilos de Arquitetura em: http://www-di.inf.puc-rio.br/~julio/DISSER01.pdf OBS.: imagens que ilustraram esta unidade foram retiradas deste material
18
NIDADE
Engenharia De Proteo Objetivo: apresentar questes que precisam se consideradas na especificao e no projeto de software seguro. A difuso do uso da Internet na dcada de 1990 introduziu um novo desafio para os engenheiros de sistemas: projetar e implementar sistemas seguros. Como mais e mais sistemas foram conectados Internet, uma variedade de diferentes ataques externos foi inventada, e eles ameaam esses sistemas. Os problemas de produo de sistemas confiveis aumentaram drasticamente. Os engenheiros de sistemas tiveram que considerar ameaas de agressores maliciosos e tecnicamente experientes, bem como problemas resultantes de erros acidentais em processos de desenvolvimento (Sommerville, 2007). As ameaas de proteo enquadram-se basicamente em trs categorias principais: 1. Ameaas confidencialidade do sistema e aos seus dados Essas ameaas podem revelar informaes a pessoas ou programas que no esto autorizados a ter acesso a elas. 2. Ameaas integridade do sistema e aos seus dados Essas ameaas podem danificar ou corromper o software ou seus dados. 3. Ameaas disponibilidade do sistema e aos seus dados Esse tipo de ameaa pode restringir acessos ao software ou a seus dados para usurios autorizados.
19
Gerenciamento de proteo no uma tarefa simples, mas inclui uma srie de atividades tais como gerenciamento de usurios e permisses, implantao e manuteno de software de sistema e monitorao, deteco e recuperao de ataques. O gerenciamento de usurios e permisses inclui adicionar e remover usurios do sistema, assegurar que os mecanismos adequados de autenticao estejam funcionando e estabelecer as permisses no sistema de modo que os usurios tenham acesso somente aos recursos de que necessitam. A implantao e manuteno de sistema de software incluem a instalao de sistema de software e de middleware e sua configurao adequada para que as vulnerabilidades de proteo sejam evitadas. Isso tambm envolve a atualizao regular desse software com as novas verses ou patches que reparam os problemas de proteo descobertos. A monitorao, deteco e recuperao de ataques incluem atividades que monitoram o sistema em relao a acessos no autorizados, detectam e colocam em funcionamento as estratgias para resistir aos ataques e atividades de back-up de modo que as operaes normais possam se reassumidas depois de um ataque externo. Para prover proteo em um sistema, deve-se utilizar uma arquitetura de camadas com os ativos crticos protegidos nos nveis mais baixos do sistema, e com vrias camadas de proteo em torno deles.
20
O nmero de camadas de proteo que uma aplicao necessita ter depende da importncia dos seus dados. A fim de acessar e modificar os registros de pacientes, um agressor precisa penetrar basicamente em trs camadas de sistema:
1. Proteo No Nvel De Plataforma O nvel mais alto controla o acesso plataforma na qual opera o sistema de registro. Isso normalmente envolve a identificao de usurio em determinado computador. A plataforma incluir tambm normalmente apoio para a manuteno da integridade de arquivos do sistema. 2. Proteo No Nvel De Aplicao O prximo nvel de proteo construdo na prpria aplicao. Ele envolve um usurio que acessa a aplicao, sendo autenticado e autorizado para realizar aes tais como visualizar ou modificar dados. O apoio de gerenciamento de integridade especfico da aplicao pode estar disponvel. 3. Proteo No Nvel De Registro Esse nvel invocado quando o acesso a registros especficos for necessrio e envolve a verificao de um usurio se est autorizado a realizar as operaes solicitadas nesses registros. A proteo nesse nvel poderia tambm envolver criptografia para assegurar que os registros no possam ser pesquisados com o uso de um navegador de arquivos. A verificao da integridade que utiliza, por exemplo, checksums criptogrficos pode detectar mudanas feitas fora dos mecanismos normais de atualizao de registros.
21
http://www.cl.cam.ac.uk/%7Erja14/book.html http://download.cissp.com.br/Ed.001_20.09.06.pdf http://camargoneves.com/Apresentacoes/unicap_proespe.pdf
Visite o interessante BLOG do profissional de Segurana da Informao Camargo Neves, destaque os principais artigos sobre o tema: http://camargoneves.com/
22
NIDADE
Diretrizes Para Um Projeto Seguro Objetivo: Apresentar diretrizes para um projeto seguro de sofware. Diferentes tipos de sistemas exigem diferentes medidas tcnicas para atingir o nvel de proteo aceitvel para o usurio do sistema. Por exemplo, um sistema bancrio exige muito mais em termos de segurana do que uma universidade, em que existe a necessidade dos sistemas terem uma segurana relativamente flexvel. No entanto, existem diretrizes gerais que tm aplicabilidade ampla quando se projetam solues de proteo de sistema que encapsulam boas prticas de projeto para sistemas seguros. As dez diretrizes de projeto que Sommerville (2007) orienta tm como objetivo tanto de conscientizar os pontos crticos de segurana, como tambm ser um checklist de reviso que pode ser usada no processo de validao de sistema. Vamos a elas:
Diretriz 1: Basear as decises de proteo em uma poltica de proteo explcita Uma poltica de proteo deve definir o que da proteo, no lugar de como. A poltica no deve definir mecanismos usados para prover e fazer cumprir a proteo. Os projetistas devem, portanto, consultar a poltica de proteo quando ela prov um framework para tomar e avaliar decises de projeto.
Diretriz 2: Evitar um ponto nico de falha Num sistema crtico uma boa prtica evitar um ponto nico de falha. Pois, uma falha nica, numa parte do sistema, pode resultar na falha geral de sistemas. Em termos de proteo, isso significa que voc no deve contar com um nico mecanismo para assegurar a
proteo, mas deve empregar vrias tcnicas distintas. Pode-se chamar isso de defesa em profundidade. Para proteger a integridade de dados o sistema, voc poderia manter um log de todas as mudanas feitas nos dados, de modo que, se ocorrer uma falha, voc poder examinar o log para recriar o conjunto de dados.
Diretriz 3: Falhar de maneira protegida Nenhuma falha de sistema deve possibilitar a um agressor acesso aos dados que no seria normalmente permitido. Portanto, embora as falhas de sistema sejam inevitveis, os sistemas crticos de segurana devem sempre falhar de maneira segura (fail-safe) e sistemas crticos de proteo devem sempre falhar de maneira protegida (fail-secure). Um uso dessa filosofia seria, por exemplo, a tcnica de numa aplicao cliente/servidor deixar um pequeno arquivo no computador cliente para facilitar o acesso aos dados. Uma vez utilizado do servio, esse arquivo eliminado. No entanto, em caso de falha esse arquivo poder ficar inseguro. Uma estratgia seria de manter essa mesma tcnica, mas com o arquivo criptografado, impossibilitando a leitura desses dados por pessoas no autorizadas.
Diretriz 4: Equilibrar proteo e facilidade de uso medida que um sistema aumenta suas caractersticas de proteo, inevitvel que ele se torne menos fcil de usar. Um bom exemplo seria os atuais sistemas bancrios na Internet. Exigem tantas chaves para acessarmos os dados, que muitas vezes provocam irritao, e perda de tempo. Portanto, chega-se a um ponto em que contraproducente manter a adio de novas caractersticas de proteo custa da facilidade de uso. Por exemplo, se voc exigir que os usurios insiram vrias senhas ou alterem suas senhas com uma constncia muito pequena,
24
eles simplesmente escrevero suas senhas em algum lugar. Um agressor poder, ento, encontrar as senhas e obter acesso ao sistema.
Diretriz 5: Estar ciente da possibilidade de Engenharia Social Em Segurana da informao, chamam-se Engenharia Social as prticas utilizadas para obter acesso s informaes importantes ou sigilosas em organizaes ou sistemas por meio da enganao ou explorao da confiana das pessoas. Para isso, o golpista pode se passar por outra pessoa, assumir outra personalidade, fingir que um profissional de determinada rea, etc. uma forma de entrar em organizaes que no necessita da fora bruta ou de erros em mquinas. Explora as falhas de segurana das prprias pessoas que, quando no forem devidamente treinadas para esses ataques, podem ser facilmente manipuladas. Do ponto de vista de projeto, enfrentar a Engenharia Social muito difcil. Mecanismos de registro que acompanham a localizao e a identificao dos usurios e os programas de anlise de registros podem tambm ser teis, na medida em que permitem detectar brechas de proteo.
Diretriz 6: Usar redundncia e diversidade para reduzir riscos Redundncia significa que voc mantm mais de uma verso de software ou de dados no sistema. Diversidade, quando aplicada ao software, significa que verses diferentes no devem ser baseadas na mesma plataforma ou usar as mesmas tecnologias. Portanto, uma vulnerabilidade de plataforma ou de tecnologia no afetar todas as verses e, dessa maneira, conduzir a falhas de modo comum. Uma aplicao dessa diretriz seria utilizar sistemas operacionais diferentes no cliente e no servidor (por exemplo: Linux no servidor e Windows no cliente). De modo a assegurar que um ataque baseado na vulnerabilidade de algum desses sistemas operacionais no afete o servidor e o cliente simultaneamente.
25
Diretriz 7: Validar todas as entradas Um ataque comum ao sistema envolve o fornecimento de entradas inesperadas ao sistema que causam um comportamento imprevisto. Pode-se evitar muito desses problemas ao se projetar uma validao de entradas no sistema. Essencialmente, nunca se deve aceitar nenhuma entrada sem aplicar alguma verificao sobre ela. Por exemplo, ningum possui um sobrenome com mais de 70 caracteres e nenhum endereo maior do que 100 caracteres. Se usar menus para apresentar as entradas permitidas, podem-se evitar alguns dos problemas de validao de entradas.
Diretriz 8: Compartilhar seus ativos Deve-se organizar a informao no sistema de modo que os usurios somente tenham acesso informao de que necessitam, no lugar de toda a informao do sistema. Pode-se tambm precisar de mecanismos no sistema para conceder acessos inesperados. Nessas circunstncias, pode-se usar um mecanismo de proteo alternativo para ignorar a compartimentalizao do sistema.
Diretriz 9: Projetar para implantao Muitos dos problemas de proteo surgem porque o sistema no est configurado corretamente quando implantado no seu ambiente operacional. Deve-se, portanto, projetar sempre os sistemas de modo que os recursos sejam includos para simplificar a implantao e para verificar erros potenciais de configurao e omisses do sistema implantado.
Diretriz 10: Projetar para capacidade de recuperao Independentemente de quanto esforo voc dispense na manuteno de proteo do sistema, voc deve sempre projetar o seu sistema com a hiptese de que uma falha de
proteo possa ocorrer. Portanto, voc deve pensar em como se recuperar de possveis falhas e restaurar o sistema para um estado operacional seguro. Por exemplo, suponhamos um ataque externo aonde uma pessoa no autorizada tenha obtido uma combinao vlida de login e senha. Voc precisa, portanto, projetar seu sistema para negar acesso a qualquer pessoa at que todos os usurios tenham alterado suas senhas e autenticar usurios reais. Uma maneira de fazer isso seria usar um mecanismo do tipo desafio/resposta, no qual os usurios precisam responder a questes para as quais possuam respostas pr-registradas. Isso seria invocado somente quando as senhas fossem alteradas.
http://pt.wikipedia.org/wiki/Seguran%C3%A7a_da_informa%C3%A7%C3%A3o http://www.sobresites.com/segurancadainformacao/
Realize uma pesquisa na Internet sobre Engenharia Social e veja filmes comerciais que j trataram desse tema.
Pesquise o excelente filme Prenda-me se for capaz.
27
NIDADE
Projeto De Interface Com O Usurio Objetivo: Apresentar Aspectos Do Projeto De Interface Com O Usurio Que So Importantes Para O Engenheiro De Sistemas. O projeto de sistema de computador abrange um espectro de atividades desde o projeto de hardware at o projeto de interface com o usurio. Enquanto os especialistas so, com frequncia, contratados para o projeto de hardware e para projetos grficos de pginas Web, somente grandes organizaes normalmente contratam projetistas especializados em interface para seu software de aplicao. Portanto, os engenheiros de software devem, muitas, vezes, assumir a responsabilidade pelo projeto de interface com o usurio, bem como pelo projeto do software para implementar essa interface. Existem basicamente trs tipos de projeto de interface tais como: 1. Projeto de Interfaces entre componentes do software. 2. Projeto de Interfaces entre o software e outros produtores e consumidores de informao no humanos (outras entidades externas). 3. Projeto de Interface entre um ser humano (o usurio) e o computador. Iremos aqui nos concentrar no ltimo tipo de Projeto de Interface onde envolvido o ser humano, comumente chamado de interface homem-computador (IHC). Existem vrias siglas nessa rea e uma delas tambm a IHM representando interface homem-mquina. Atualmente as interfaces mais comuns so as seguintes: Interface grfica do usurio GUI (Graphical User Interface): aceita a entrada atravs de sistemas como o teclado ou mouse e fornece sada grfica articulada no monitor.
Interface web do usurio - aceita a entrada e fornece sada ao gerar pginas web, que so transportadas pela Internet e visualizadas atravs de um navegador.
Interface de linha de comando - aceita a entrada atravs de comandos de texto utilizando o teclado e fornece como sada caracteres no monitor.
Interface ttil - interface grfica do usurio que usa telas sensveis ao toque (touch screen) como forma de entrada, tornando o monitor um dispositivo tanto de entrada como de sada do sistema.
Conforme vemos na figura a seguir, a interface com o usurio (IU) intermedeia o homem com a mquina. Existem processamentos de ambos os lados (pensar), e interpretaes das mensagens encaminhadas para cada um deles (ler), assim como respostas a tudo isso (responder). Quanto mais simples for todo esse processo maior o sucesso da interface.
29
Defina os modos de interao Proporcione interao flexvel Permita a interrupo e o desfazer Coloque o usurio No controle Simplifique a interao e permita a personalizao Esconda detalhes tcnicos Faa a interao direta com os objetos na tela REGRAS OURO PROJETO INTERFACE (Theo 1997) Mandel, Reduza a carga de DE NO DE Reduza a necessidade de memria de curto prazo Estabelea defaults significativos Defina atalhos intuitivos Interface anloga ao mundo real Revele progressivamente Situe o usurio dentro do contexto maior Faa a interface Mantenha consistncia Se modelos anteriores foram informaes
memria do usurio
consistente
significativos p/ os usurios no modificar
30
Vejamos na figura a seguir que podemos projetar numa arquitetura Cliente-Servidor (lado direito), divises estratgicas para o nosso usurio. Numa aplicao como um todo, podemos dividi-la com a parte mais sistmica do lado servidor, e as interaes com o usurio do lado cliente (lado esquerdo).
Quando o desenvolvimento interativo usado, o projeto de interface com o usurio prossegue incrementando-se, medida que o software desenvolvido. Algumas vezes, o prottipo da interface desenvolvido separadamente, em paralelo com outras atividades de engenharia de software. Em ambos os casos, contudo, antes de iniciar a programao, voc deve ter desenvolvido e, de preferncia, testado alguns projetos baseados em papel. Existem trs atividades principais nesse processo: Anlise de usurio: No processo de anlise de usurio, voc desenvolve uma compreenso das tarefas que os usurios realizam, seus ambientes de trabalho, os outros sistemas que eles usam, como eles interagem com outras pessoas em seu trabalho, etc. Para produtos com vrios usurios, voc deve tentar desenvolver essa compreenso por meio do foco em grupos, ensaios com usurios potenciais e exerccios similares.
Prototipao de Sistema: O projeto e desenvolvimento da interface com o usurio um processo interativo. Embora os usurios possam informar sobre os recursos de interface de que necessitam, muito difcil para eles serem especficos at que vejam algo tangvel. Portanto, voc deve desenvolver sistemas de prottipo e exp-los aos usurios, que podero, ento, guiar a evoluo da interface. Avaliao da Interface: Embora haja, obviamente, discusses com os usurios durante o processo de prototipao, voc deve tambm ter uma atividade de avaliao mais formalizada, na qual sejam coletadas informaes sobre a experincia do usurio com a interface. O cronograma de projeto de UI dentro do processo de software depende, em alguma extenso, de outras atividades. A prototipao pode ser usada como parte do processo de engenharia de requisitos e, nesse caso, faz sentido iniciar o processo de projeto de UI por esse estgio. Nos processos interativos, o projeto de UI integrado ao desenvolvimento de software. Como o software propriamente dito, a UI deve passar por refactoring e reprojeto durante o desenvolvimento.
http://pt.wikipedia.org/wiki/Interface_do_utilizador http://www.pucrs.campus2.br/~jiani/trabalhos/levacov.htm http://www.dcce.ibilce.unesp.br/~ines/cursos/eng_soft/aula11.PDF http://www.dimap.ufrn.br/~jair/piu/JAI_Apostila.pdf
32
Verifique em sua empresa, ou na de colegas, seus principais sistemas e faa uma anlise crtica sobre as suas interfaces de usurio.
33
NIDADE
Gerenciamento De Pessoal Objetivo: Explicar a importncia das pessoas no processo de Engenharia de Sistemas. A experincia mostra que, medida que o nmero de pessoas em uma equipe de projeto de software aumenta, a produtividade global do grupo pode sofrer. Um modo de contornar esse problema criar vrias equipes de engenharia de software, compartimentalizando consequentemente as pessoas em grupos de trabalhos individuais. No entanto, enquanto o nmero de equipes de engenharia de software cresce, a comunicao entre elas se torna to difcil e demorada quanto a comunicao entre indivduos. Pior, a comunicao (entre indivduos ou equipes) tende a ser ineficiente isto , gasta-se muito tempo transferindo muito pouco contedo de informao e, muito frequentemente, informao importante se perde nas frestas (Pressman, 2006). Se a comunidade de engenharia de sistemas tiver que lidar efetivamente com o dilema de comunicao, a estrada adiante, para os engenheiros de software incluir modificaes radicais no modo pelo qual indivduos e equipes comunicam-se uns com os outros. E-mail, sites Web e vdeo-conferncia centralizada so agora comuns como mecanismos para conectar um grande nmero de pessoas a uma rede de informao. A importncia dessas ferramentas no contexto do trabalho de engenharia de software no pode ser por demais enfatizada. Com um sistema efetivo de correio eletrnico ou sistema de mensagem instantnea, o problema encontrado por um engenheiro em Nova York pode ser resolvido com ajuda de um colega em Tquio. Em um sentido muito real, sesses de conversa (chat sessions) bem focadas e grupos de interesse especializados tornam-se repositrios de conhecimento que permitem que a
34
sabedoria coletiva de um grande nmero de tecnlogos seja concentrada em um problema tcnico ou em um assunto gerencial. A boa comunicao entre os membros de um grupo de desenvolvimento de software essencial. Os membros do grupo devem trocar informaes sobre o status do seu trabalho, as decises de projeto tomadas e as mudanas necessrias em decises anteriores. A boa comunicao tambm fortalece a coeso do grupo uma vez que os membros passam a compreender as motivaes, os pontos fortes e fracos de outras pessoas no grupo. Os fatores principais que influenciam a eficincia da comunicao so: Tamanho do grupo: medida que um grupo cresce em tamanho, torna-se mais difcil assegurar que todos os membros se comuniquem eficientemente uns com os outros. O nmero de elos de comunicao em uma direo n(n-1), sendo n o tamanho do grupo; portanto, por exemplo, num grupo de sete a oito membros, muito provvel que algumas pessoas raramente se comuniquem. Estrutura do grupo: As pessoas em grupos estruturados informalmente se comunicam com mais eficincia do que as pessoas em grupos com uma estrutura formal e hierrquica. As pessoas de nvel podem no conversar umas com as outras. Esse um problema especfico em um projeto de grande porte com vrios grupos de desenvolvimento. Quando as pessoas que trabalham em subsistemas diferentes se comunicam somente por meio de seus gerentes, o projeto pode sofrer atrasos e haver desentendimentos. Composio do grupo: Pessoas com o mesmo tipo de personalidade podem entrar em conflito e a comunicao pode ficar comprometida. A comunicao geralmente melhor em grupos compostos de homem e mulheres do que em grupos com pessoas de mesmo sexo, conforme estudos de Marshall e Heslin (1975). As mulheres tendem a ser mais orientadas a interaes do que os homens, e podem atuar como controladoras e facilitadoras das interaes do grupo.
Ambiente fsico de trabalho: A organizao do local de trabalho um fator importante para facilitar ou inibir as comunicaes. Um estudo realizado por McCue (1978) mostrava que a arquitetura plana e aberta fornecida por muitas organizaes no era popular nem produtiva. Os fatores mais importantes identificados nesse estudo foram: Privacidade: Programadores rendem melhor em lugares mais fechados. Conscincia Externa: Pessoas preferem luz natural e com viso do exterior. Personalizao: Os indivduos adotam diferentes prticas de trabalho e tm opinies diferentes sobre a decorao. A possibilidade de reorganizar o espao para se adequar s prticas de trabalho e poder personalizar esse ambiente importante.
Um dos papeis do gerente de projeto motivar as pessoas que trabalham com ele. Motivao significa organizao do trabalho e ambiente de trabalho de forma que as pessoas se sintam estimuladas a trabalhar to eficientemente quanto possvel. Se as pessoas no esto motivadas, elas no tero interesse no trabalho que esto realizando. Elas trabalharo lentamente, sero mais propensas a cometer erros e no contribuiro para as metas mais amplas da equipe ou da organizao. Das necessidades registradas por Maslow (1954) na sua famosa pirmide das necessidades humanas, as que mais afetam as pessoas que trabalham em organizaes de desenvolvimento de software so as necessidades de satisfao social, autoestima e autorealizao.
36
http://pt.wikipedia.org/wiki/Gest%C3%A3o_de_recursos_humanos
Faa uma pesquisa sobre o impacto da Gesto de Recursos Humanos na equipe de tecnologia
37
NIDADE
Modelos De Gerenciamento De Pessoal Objetivo: Apresentar modelos de gerenciamento de pessoal relacionados com a tecnologia de sistemas. Modelo De Maturidade De Capacitao De Pessoal (P-Cmm) O Software Engineering Institute (SEI) nos Estados Unidos est engajado em um programa de longo prazo de aprimoramento do processo de software. Parte desse programa, como j vimos, o Modelo de Maturidade de Capacitao CMM (Capability Maturity Model). Ele est relacionado com as melhores prticas em Engenharia de Software. Para apoiar esse modelo, o instituto tambm props o Modelo de Maturidade de Capacitao de Pessoal P-CMM (People Capability Maturity Model). O P-CMM pode ser usado como framework de aprimoramento da maneira pela qual uma organizao gerencia seu patrimnio humano. Assim como o CMM, o P-CMM um modelo de cinco nveis, conforme ilustrado na figura a seguir.
38
O P-CMM refora a necessidade de reconhecer a importncia das pessoas como indivduos e de desenvolver suas capacidades. uma ferramenta prtica para aprimoramento do gerenciamento de pessoal em uma organizao, pois fornece um framework para motivao, reconhecimento, padronizao e aprimoramento de boas prticas. Entretanto, como todos os modelos de capacitao criados pelo SEI, ele projetado para grandes empresas, no levando em conta as pequenas. Naturalmente, a aplicao completa desse modelo muito dispendiosa e, provavelmente, desnecessria para a maioria das organizaes. Contudo, ele um guia til que pode conduzir a melhorias significativas na capacidade da organizao em produzir software de qualidade. PSP - Personal Software Process PSP um processo de software focado para engenheiros de software individuais. O PSP foi desenvolvido por Watts Humphrey e est descrito no seu livro "A Discipline for Software Engineering" (Uma disciplina para Engenheiros de Software) de 1995. O PSP foi desenvolvido para guiar como planejar e desenvolver mdulos de software ou pequenos programas, mas pode ser adaptado para outras tarefas pessoais. O PSP, assim como o CMM, baseado no princpio da melhoria do processo. Enquanto o CMM focado da melhoria da capacidade organizacional, o foco do PSP no profissional de software. Os objetivos principais do PSP so: Melhorar as estimativas; Melhorar o planejamento e o acompanhamento de cronogramas; Proteger contra o excesso de compromissos; Criar um comprometimento pessoal para a qualidade; Envolvimento contnuo do engenheiro na melhoria continua do processo;
Alm disso, favorece a melhoria da capacidade organizacional como um todo ao melhorar o trabalho individual.
Em 1997 Will Hayes e James W. Over fizeram um estudo com 298 engenheiros de software e o resultado deste estudo est disponvel no relatrio tcnico "An Empirical Study of Impact of PSP on Individual Engineers" disponvel no site da SEI. No estudo eles verificaram o impacto da implantao do PSP. Como resultados obtidos podemos citar: Uma melhoria de 75% (em mdia) na estimativa de esforo; Uma melhoria de 150% (em mdia) na estimativa de tamanho; A tendncia de subestimar o tamanho e o esforo foram reduzidos. E o nmero de sobrestimativas e de subestimativas foi balanceado; Qualidade do Produto: os defeitos encontrados em uma unidade de produto testada melhoraram em uma relao de 2.5 vezes (em mdia); Qualidade do Processo: os defeitos encontrados antes da compilao aumentaram em 50% (em mdia); Produtividade Pessoal: o nmero de linhas de cdigo por hora no alterou substancialmente. Mas a melhoria da qualidade do produto resulta na melhora da produtividade do ciclo de desenvolvimento. Testes de produto e testes de integrao so executados mais rapidamente por causa da melhoria da qualidade do produto, diminuindo assim o ciclo de desenvolvimento. O PSP uma ferramenta que pode ser aplicada em qualquer estrutura organizacional. Pode ser introduzida em qualquer modelo de desenvolvimento. Melhora a qualidade de desenvolvimento pessoal tornando-se uma ferramenta indispensvel em pequenos projetos e serve de grande auxlio em projetos maiores. Aumenta a qualidade do produto, pois tem-se um esforo de deteco de erros antes mesmo da fase de testes (simplificando e barateando esta fase).
40
http://blog.marcomendes.com/category/gestao-de-pessoas/ http://www.sei.cmu.edu/tsp/psp.html http://pt.wikipedia.org/wiki/Personal_software_process www.ufpel.tche.br/prg/sisbi/bibct/acervo/info/2000/Mono-JoseWilson.pdf www.simpros.com.br/simpros2005/upload/A04_2_artigo14181.pdf http://www.dsc.ufcg.edu.br/~patricia/esii2001.1/materialaulas/aula02.pdf
Veja a aplicabilidade do PSP testando o software de apoio a implantao dessa tcnica em: http://processdash.sourceforge.net/
41
NIDADE
Gerenciamento De Qualidade Objetivo: Explicar o gerenciamento de qualidade, como o SWEBOK trata esse tema e os padres existentes. A qualidade de software tem se aprimorado significativamente nos ltimos 15 anos. Uma razo para isso o fato de as empresas terem adotado novas tcnicas e tecnologia, como o uso de desenvolvimento orientado a objetos e de ferramenta de apoio CASE associada. Alm disso, contudo, tem havido uma conscientizao maior da importncia do gerenciamento de qualidade de software e da adoo de tcnicas de gerenciamento de qualidade provenientes da manufatura de software. Entretanto, qualidade de software um conceito complexo que no diretamente comparvel com a qualidade na manufatura. Na manufatura, a noo de qualidade tem sido aquela em que o produto desenvolvido deve atender s suas especificaes conforme Crosby (1979). Em um mundo ideal essa definio deveria ser aplicada a todos os produtos, mas, para sistemas de software, h problemas com isso, pois: A especificao deve se orientada para as caractersticas do produto que o cliente deseja. Entretanto, a organizao que desenvolve pode tambm ter requisitos (como requisitos de facilidade de manuteno) que no esto includos na especificao; No sabemos como especificar certas caractersticas de qualidade (por exemplo, facilidade de manuteno) de maneira no ambgua; Conforme a engenharia de requisitos, muito difcil escrever especificaes de software completas. Portanto, embora um produto de software possa estar de acordo com a sua especificao, os usurios podem mesmo assim no consider-lo como um
42
produto de alta qualidade, pelo fato do software entregue no corresponder s suas expectativas. Para um melhor entendimento e estudo, o SWEBOK divide a Qualidade de Software em trs tpicos, cada tpico subdividido em atividades, da seguinte forma: 1. Fundamentos de Qualidade de Software Cultura e tica de Engenharia de Software Valores e Custos de Qualidade Modelos e Caractersticas de Qualidade Melhoria da Qualidade
2. Gerncia do Processo de Qualidade de Software Garantia de Qualidade de Software Verificao e Validao Revises e Auditorias
3. Consideraes Prticas Requisitos de Qualidade para Aplicaes Caracterizao de Defeitos Tcnicas de Gerncia de Qualidade de Software Medidas de Qualidade de Software
Ainda segundo o SWEBOK, a Qualidade de Software um tema to importante que encontrado, de forma ubqua, em todas as outras reas de conhecimento envolvidas em um projeto. Alm disso, ele deixa claro que essa rea, como nele definido, trata dos aspectos estticos, ou seja, daqueles que no exigem a execuo do software para avali-lo, em
contraposio rea de conhecimento Teste de software. Porm, normal que se encontrem autores e empresas que afirmam serem os Testes de Software uma etapa da Qualidade de Software.
Para sistemas menores, o gerenciamento da qualidade ainda importante, mas uma abordagem mais informal pode ser adotada. Nem tanta papelada necessria porque uma equipe pequena de desenvolvimento pode se comunicar informalmente. A questo principal de qualidade para desenvolvimento de sistemas pequenos estabelecer uma cultura de qualidade e assegurar que todos os membros da equipe tenham uma abordagem positiva para a qualidade de software.
44
O gerenciamento de qualidade de software para sistemas de grande porte pode ser estruturado em trs atividades principais: Garantia de Qualidade: Estabelecimento de um framework de procedimentos organizacionais e padres que conduzem a um software de alta qualidade. Planejamento de Qualidade: Seleo de procedimentos e padres apropriados deste framework, adaptados para um projeto de software especfico. Controle de Qualidade: Definio e aprovao de processos que assegurem que a equipe de desenvolvimento de software tenha seguido os procedimentos e os padres de qualidade do projeto.
O gerenciamento de qualidade de processo envolve: Definio de padres de processo, como como e quando as revises devem ser conduzidas. Monitorao do processo de desenvolvimento para assegurar que os padres esto sendo seguidos. Relato do processo de software para a gerncia de projeto e para o comprador do software.
Os dois tipos de padres que podem ser estabelecidos como parte do processo de garantia de qualidade so:
45
PADRES de PRODUTO: Esses padres se aplicam especifica-mente ao produto de software em desenvolvimento. Eles incluem padres de documentos, como a estrutura de documentos de requisitos, padres de documentao, como um cabealho de comentrio padronizado para uma definio de classe de objeto; e padres de codificao, que definem como uma linguagem de programao deve ser utilizada. PADRES de PROCESSO: Esses padres definem os processos que devem ser seguidos durante o desenvolvimento de software. Podem incluir definies de processos de especificao, projeto e de validao, e uma descrio dos documentos que devem ser escritos ao longo destes processos.
http://pt.wikipedia.org/wiki/Qualidade_de_Software
Um colega, que programador muito bom, produz software com baixo nmero de defeitos, mas ele simplesmente ignora os padres de qualidade da organizao. Se voc fosse o gerente dessa equipe como reagiria em relao a esse comportamento?
46
NIDADE
Padro De Qualidade - Iso 9001 Objetivo: Mostrar o histrico da ISO 9000 e o impacto na rea de Tecnologia. Um conjunto internacional de padres que pode ser usado no desenvolvimento de um sistema de gerenciamento de qualidade em todas as indstrias chamado de ISO 9000. Os padres ISO 9000 podem ser aplicados para uma variedade de organizaes, desde a indstria de manufatura at a indstria de servio. O padro ISO 9001 o mais geral desses padres e se aplica s organizaes que se dedicam a processos de qualidade nas empresas que projetam, desenvolvem e mantm produtos. Um documento de apoio (ISO 9000-3) interpreta a ISO 9001 para o desenvolvimento de software. Vrios livros descrevem o padro ISO 9001. O padro ISO 9001 no especificamente voltado para o desenvolvimento de software, mas estabelece princpios gerais que podem ser aplicados ao software. O padro ISO 9001 descreve vrios aspectos do processo de qualidade e exibe os padres e os procedimentos organizacionais que a empresa deve definir. Eles devem ser documentados em um manual de qualidade da organizao. A definio de processo deve incluir descries da documentao necessria para demonstrar que os processos definidos foram seguidos durante o desenvolvimento do produto.
47
O padro ISO 9001 no define os processos de qualidade que devem ser usados. De fato, ele no restringe de modo nenhum os processos usados em uma organizao. Isso permite flexibilidade por meio de setores industriais e significa que pequenas empresas podem ter processos no burocrticos e, ainda assim, estar em conformidade com a norma. Contudo, essa flexibilidade significa que voc no pode fazer quaisquer suposies sobre a similaridade ou a diferena entre os processos nas empresas em conformidade a ISO 9001. Os procedimentos de garantia de qualidade de uma organizao so documentados em um manual que define o processo de qualidade. Em alguns pases, as autoridades certificadoras asseguram que o processo de qualidade, conforme expresso no manual de qualidade, est em conformidade ao padro ISO 9001. Cada vez mais, os clientes procuram pela certificao ISO 9000 de um fornecedor como um indicador de com que seriedade esse fornecedor trata a qualidade. Algumas pessoas pensam que a certificao ISO 9000 significa que a qualidade do software produzido pelas empresas certificadas ser melhor do que a das empresas sem certificao. Esse certamente no o caso. O ISO 9000 est simplesmente relacionado com a definio de processos que sero usados em uma empresa e a documentao associada, como
processos de controle que podem explicitamente mostrar que esses processos foram seguidos. Isso no est relacionado com a garantia de que os processos refletem as melhores prticas ou com a qualidade de produto. Portanto, digamos que uma empresa possa definir procedimentos de teste de produto que conduzam aos testes de softwares incompletos. Assim, medida que esses processos forem seguidos e documentados, a empresa estaria seguindo o padro ISO 9001. Enquanto essa situao for indesejvel, no h dvida de que alguns padres de empresas sero muito inadequados e traro pouca contribuio para a real qualidade de software. Padres de documentao: Em um projeto de software so importantes porque os documentos so o nico modo tangvel de representao do software e do processo desse. Existem trs tipos de padres de documentao: Padres de Processo de Documentao: Esses padres definem o processo que deve ser seguido para a produo de documentos. Padres de Documentos: Esses padres regem a estrutura e a apresentao fsica dos documentos. Padres de Intercmbio de Documentos: Esses padres asseguram que todas as cpias eletrnicas de documentos sejam compatveis.
49
http://pt.wikipedia.org/wiki/ISO_9000 http://www.inmetro.gov.br/qualidade/docOrientativo.asp
Leia o importante documento sobre a aplicabilidade do padro de qualidade ISO 9001 em: www.bsibrasil.com.br/documentos/What_is_9kBR.pdf
50
NIDADE
10
Desenvolvimento De Sistemas Crticos Objetivo: apresentar tcnicas de implementao usadas no desenvolvimento de sistemas crticos. Tcnicas de Engenharia de Sistemas avanadas, linguagens de programao aprimoradas e melhor gerenciamento de qualidade conduziram a aprimoramentos significativos na confiabilidade da maioria dos softwares. Entretanto, sistemas crticos, como os que controlam mquinas no assistidas, sistemas mdicos, comutadores de telecomunicaes ou aeronaves necessitam de nveis mais altos de confiabilidade. Nesses casos, tcnicas especiais de desenvolvimento podem ser usadas para assegurar que o sistema seja seguro, protegido e confivel. Existem basicamente trs abordagens complementares para desenvolver um software confivel: Preveno de Defeitos: O processo de projeto e de implementao do sistema deve usar abordagens de desenvolvimento de software que ajudem a evitar erros de programao e, assim, minimizar o nmero de defeitos de um programa. Deteco de Defeitos: Os processos de verificao e validao so projetados para descobrir e remover defeitos de um programa antes que este seja implantado para uso operacional. Tolerncia a defeitos: O sistema projetado de forma que os defeitos ou o comportamento inesperado do sistema, durante a execuo, sejam detectados e gerenciados de modo que a falha do sistema no ocorra.
Fundamentais para a confiabilidade de qualquer sistema so as noes bsicas de redundncia e diversidade. Estas so estratgias cotidianas de proteo para evitarem falhas. Se voc est investindo na bolsa, no deve alocar todos os seus investimentos numa nica empresa, pois poder perder tudo se a empresa vier a falir (diversidade). As pessoas guardam pilhas e lmpadas reservas em seus lares para que possam se recuperar rapidamente de falhas (redundncia). Todos ns devemos fazer back-up de nossos computadores regularmente em casos de falha no disco (redundncia) e, para proteger nossos lares em termos de segurana, geralmente temos mais de um tipo de fechadura na porta principal de entrada (diversidade). Sistemas crticos podem incluir componentes que replicam a funcionalidade de outros componentes (redundncia) ou cdigo adicional de verificao que no estritamente necessrio para que os sistemas funcionem (redundncia). Portanto, os defeitos podem ser detectados antes que causem falhas, e o sistema poder ser capaz de dar continuidade operando caso os componentes individuais falhem. Se os componentes redundantes no forem os mesmos que outros componentes (diversidade), uma falha em comum no mesmo componente replicado no resultar na falha completa do sistema. Em sistemas em que a disponibilidade um requisito crtico, servidores redundantes so normalmente disponibilizados. Eles entram em operao automaticamente caso um servidor designado falhe. Algumas vezes, para assegurar que ataques ao sistema no possam explorar uma vulnerabilidade comum, os servidores podem ser de tipos diferentes e executar diferentes Sistemas Operacionais. O uso de Sistemas Operacionais diferentes um exemplo concreto de diversidade e de redundncia de software.
Infelizmente, incluir diversidade e redundncia nos sistemas torna-os mais complexos e, dessa maneira, mais difceis de compreender. Portanto, mais provvel que os programadores venham a cometer erros e menos provvel que pessoas, ao verificar os programas, encontrem erros. Consequentemente, algumas pessoas consideram melhor evitar a redundncia e a diversidade em um software para que o desenvolvimento do sistema seja to simples e seguro quanto possvel, e ter procedimentos de verificao e validao extremamente rigorosos. Ambas as abordagens so utilizadas em sistemas de segurana comerciais crticos. O sistema de controle de vo do Airbus 340 redundante e tem diversidade, enquanto o sistema de controle de vo do Boeing 777 baseia-se em uma nica verso de software. Um dos objetivos da pesquisa em Engenharia de Sistemas tem sido desenvolver ferramentas, tcnicas e mtodos que conduzam a uma produo de software livre de defeitos. Um software livre de defeitos o que atende exatamente a sua especificao. Entretanto, isso no significa que o software nunca ir falhar. Podem ocorrer erros na especificao que sero refletidos no software ou os usurios podem no compreender ou usar inapropriadamente o sistema de software. No entanto, a eliminao de defeitos do software tem certamente impacto enorme no nmero de falhas do sistema.
53
http://www.dstan.mod.uk/ http://www.poli.usp.br/pro/procsoft/tpcsepusp03.pdf http://www.lbd.dcc.ufmg.br:8080/colecoes/sbes/2001/002.pdf
Realize uma pesquisa na Internet sobre Sistemas Crticos que no tiveram sucesso. Existem vrios casos que ficaram famosos na histria ...
Antes de dar continuidades aos seus estudos fundamental que voc acesse sua SALA DE AULA e faa a Atividade 1 no link ATIVIDADES.
54
NIDADE
11
Desenvolvimento De Sistemas Crticos (Continuao) Objetivo: Dar continuidade aos aspectos do desenvolvimento de Sistemas Crticos. Para sistemas de pequeno e mdio porte, as tcnicas de Engenharia de Software provavelmente tornam possvel desenvolver software livre de defeitos. Para atingir esse objetivo, voc precisa usar uma gama de tcnicas de Engenharia de Software: Processos de Software Confiveis: O uso de um processo de software confivel com atividades de validao e verificao apropriadas essencial caso o nmero de defeitos em um programa deva ser minimizado e aqueles ignorados devam ser detectados. Gerenciamento de Qualidade: A organizao que desenvolve o sistema deve ter uma cultura na qual a qualidade conduz o processo de software. A cultura organizacional deve estimular os programadores a criar programas livres de defeitos. Padres de desenvolvimento e projeto devem ser estabelecidos e procedimentos devem estar disponveis para verificar se os padres foram seguidos. Especificao Formal: Deve haver uma especificao precisa (de preferncia formal) que defina o sistema a ser implantado. Muitos defeitos de projeto e programao resultam de uma interpretao errada de uma especificao ambgua ou mal especificada.
55
Verificao Esttica: Tcnicas de verificao esttica, como o uso de analisadores estticos, podem encontrar caractersticas anmalas de programao que podem ser defeitos. A verificao formal, baseada na especificao do sistema, tambm pode ser usada. Tipagem Forte: Uma linguagem de programao com tipos fortes de dados, como Java ou ADA, deve ser usada para o desenvolvimento. Se a linguagem tiver tipagem forte, o compilador poder detectar muitos defeitos de programao antes que sejam includos no programa a ser entregue. Programao Segura: Algumas construes da linguagem de programao so mais complexas e propensas a erros do que outras, e ser mais provvel cometer erros caso sejam usadas. A programao segura significa evitar, ou ao menos minimizar, o uso dessas construes. Informaes Protegidas: Deve ser usada uma abordagem para projeto e implementao de software baseada em ocultamento e encapsulamento de informaes. Linguagens orientadas a objetos, como Java, obviamente satisfazem essa condio. Deve ser encorajado o desenvolvimento de programas projetados para facilidade de leitura e compreenso. As empresas de desenvolvimento de software admitem que seu software sempre conter alguns defeitos residuais. O nvel de defeitos depende do tipo de sistema. Produtos comerciais tm nvel relativamente alto de defeitos, embora estejam muito melhores que h dez anos, enquanto sistemas crticos tm, normalmente, uma densidade de defeitos menor. A lgica para a aceitao de defeitos que, se e quando o sistema falhar, mais vantajoso pagar pelas consequncias da falha do que descobrir e remover os defeitos antes da entrega final do sistema. No entanto, a deciso de liberar o software com defeitos no s
56
econmica. A aceitao poltica e social, ou seja, a imagem da empresa no mercado, da falha do sistema tambm deve ser considerada.
Como voc enxerga o contedo apresentado nesta unidade com o restante da nossa apostila? Existem itens relacionados?!?
57
NIDADE
12
Arquiteturas Tolerantes A Defeitos Objetivo: Visualisar as arquiteturas clssicas de hardware e as de software tolerantes a falhas. Em muitos sistemas, possvel implementar a tolerncia aos defeitos de software por meio da incluso explcita de aes de verificao e recuperao no software. Isso denominado programao defensiva. Contudo, essa abordagem no trabalha eficientemente com defeitos do sistema que surgem com base em interaes entre o hardware e o software. Alm disso, a m compreenso dos requisitos pode significar que tanto o cdigo do sistema quanto a defesa associada esto incorretos. Para a maioria dos sistemas crticos, particularmente aqueles com requisitos rigorosos de disponibilidade, pode ser necessria uma arquitetura especfica projetada para apoiar a tolerncia a defeitos. Exemplos de sistemas que usam essa abordagem de tolerncia a defeitos so os sistemas de aviao, que devem estar em operao durante o vo, os sistemas de telecomunicaes, e os sistemas crticos de comando e controle. H muitos anos existe a necessidade de se construir hardware tolerante a defeitos. A tcnica de hardware tolerante a defeitos mais comum baseada na noo de redundncia modular tripla TMR (Triple-Modular Redundancy). A unidade de hardware replicada trs (ou algumas mais) vezes. A sada de cada unidade passa para um comparador de sada normalmente implementado como um sistema de votao. Se uma das unidades falha e no produz a mesma sada que as outras unidades, sua sada ignorada. Veja a figura a seguir:
58
A1
A2
Comparador de sada
A3
Um gerenciador de defeitos pode tentar reparar a unidade defeituosa automaticamente, mas se isso for impossvel, o sistema ser automaticamente reconfigurado para tirar a unidade de servio. Em seguida, o sistema continuar a funcionar com duas unidades operando. Atravs dessa tcnica que foi possvel a NASA colocar o homem na lua. Embora com computadores precrios e extremamente simples, foi somente com esse tipo de arquitetura tolerante a falhas que foi possvel garantir o pleno sucesso dessa misso. Essa abordagem de tolerncia a defeitos baseia-se no fato de que a maioria das falhas de hardware resultante das falhas de componente em vez de ser ocasionada por defeitos de projeto. Os componentes so, portanto, propensos a falhar independentemente. Supe-se que, quando completamente operacionais, todas as unidades de hardware operem de acordo com a especificao. H, portanto, baixa probabilidade de falha simultnea de componentes em todas as unidades de hardware. Naturalmente, todos os componentes poderiam ter um defeito de projeto em comum e, assim, todos produziriam a mesma resposta errada. Usando unidades de hardware com uma especificao em comum, mas projetadas e construdas por fabricantes diferentes, reduzemse as chances de uma falha de modo comum. Presume-se que a probabilidade de equipes diferentes cometerem o mesmo erro de projeto ou de fabricao seja bem pequena.
Se os requisitos de disponibilidade e confiabilidade de um sistema forem tais que voc necessite usar um hardware tolerante a falhas, voc pode tambm precisar de um software tolerante a defeitos. Existem duas abordagens para fornecer software tolerante a defeitos. Ambas as tcnicas foram derivadas do modelo de hardware em que componentes, ou sistemas, redundantes so includos e componentes defeituosos podem ser desativados. As duas abordagens para tolerncia a defeitos de software so: Programao Em N-Verses: Usando uma especificao comum, o sistema de software implementado em uma srie de verses por diferentes equipes. Essas verses so executadas paralelamente em computadores separados. Suas sadas so comparadas com a utilizao de um sistema de votao, e sadas inconsistentes ou sadas no produzidas em tempo, so rejeitadas. No mnimo trs verses de sistema devem ser disponibilizadas de modo que duas verses sejam consideradas consistentes no evento de uma nica falha. Essa a abordagem mais comum usada para tolerncia a defeitos de software. Ela foi usada em sistemas de sinalizao de ferrovias, em sistemas de aviao e em sistemas de proteo de reatores. Blocos De Recuperao: Nessa abordagem, cada componente do programa inclui um teste para verificar se o componente foi executado com sucesso. Tambm inclui um cdigo alternativo que permite ao sistema fazer uma cpia e repetir o processamento se o teste detectar uma falha. As implementaes so, deliberadamente, interpretaes diferentes da mesma especificao. Elas so mais executadas em sequncia do que em paralelo. Dessa maneira, o hardware replicado no necessrio. Na programao em n-verses, as implementaes podem ser diferentes, mas no incomum que duas ou mais equipes escolham o mesmo algoritmo para implementar a especificao.
60
www.ic.unicamp.br/~beatriz/projetos/bpm/CIAWI07_A%20Fault%20Tolerant%20Arc hitecture%20for.pdf
Fornea motivos pelos quais as verses de sistema na abordagem de programao em n-verses possam falhar de maneira similar.
61
NIDADE
13
Estratgias De Teste De Software Objetivo: Abordar a problemtica da realizao de testes com a equipe de desenvolvimento e como organiz-la para essa atividade. Uma estratgia de testes de software deve ser suficientemente flexvel para promover uma abordagem de teste sob medida. Ao mesmo tempo, deve ser suficientemente rgida para promover planejamento razovel e acompanhamento gerencial, medida que o projeto progride. Shooman discute esses pontos da seguinte forma:
Sob vrios aspectos, o teste um processo independente e o nmero de tipos diferentes de teste varia tanto quanto as diferentes abordagens de desenvolvimento. Durante muitos anos, nossa nica defesa contra erros de programao era o projeto cuidadoso e a inteligncia prpria do programador. Estamos agora em uma era em que tcnicas modernas de projeto esto nos ajudando a reduzir o nmero de erros iniciais que so inerentes ao cdigo. Analogamente, diferentes mtodos de teste esto comeando a se agregar em vrias abordagens e filosofias distintas.
62
Em cada projeto de software h um conflito de interesses que ocorre quando o teste comea. O pessoal que construiu o software agora solicitado a test-lo. Isso parece incuo em si mesmo, afinal de contas, quem conhece o programa melhor de que seus desenvolvedores? Infelizmente, esses mesmos desenvolvedores tm interesses ocultos em demonstrar que o programa est livre de erros, que funciona de acordo com os requisitos do cliente e que ser completado de acordo com o cronograma e dentro do oramento. Cada um desses interesses se contrape a um teste rigoroso. Conforme a figura anterior o desenvolvedor de software (programador) sempre responsvel por testar as unidades individuais do programa (teste de unidade), tanto testes funcionais quanto estruturais, garantindo que cada uma realiza a funo ou exibe o comportamento para o qual foi projetada. Em muitos casos, o desenvolvedor tambm conduz os testes de integrao uma etapa de teste que leva construo da arquitetura completa do software. Um programador designado realiza o teste de integrao de cada mdulo com os demais mdulos do sistema (esta pessoa preferencialmente no deve ter participado do desenvolvimento). Apenas depois da arquitetura do software ser completada, um grupo independente de teste (equipe de homologao) comea a ser envolvido. O papel do grupo independente de teste (Independent Test Group ITG) remover os problemas inerentes associados de deixar o construtor testar o software que ele construiu. O teste independente remove o conflito de interesses que pode, de outra forma, estar presente. Afinal de contas, o pessoal de ITG pago para encontrar erros. As caractersticas da equipe ITG devem ser especiais e a escolha de seus profissionais com critrio. interessante que sejam pessoas que no se envolveram no processo de desenvolvimento, e profissionais que conheam o domnio do negcio. Exemplos: Analistas de negcio, profissionais mais antigos (no caso de softwares de uso interno), e profissionais que atuam no help-desk da empresa.
63
O ITG parte da equipe do projeto de desenvolvimento de software no sentido de que esteve envolvido durante a anlise e o projeto e continua envolvido ao longo de um projeto de grande porte. No entanto, em muitos casos, o ITG pertence equipe de garantia da qualidade de software, alcanando assim um grau de independncia que poderia no ser possvel se ele fizesse parte da organizao de Engenharia de Software. Durante a conduo do Teste de Sistema, o desenvolvedor deve estar disponvel para corrigir os erros eventualmente descobertos. Em seguida, dever ser realizado o Teste de Aceitao aonde usurios reais do sistema so selecionados e convidados a realizarem testes alfa e beta do sistema. Estes usurios devem ter: Boa capacidade crtica Certa cumplicidade com a empresa desenvolvedora J ser usurio de outros sistemas desenvolvidos pela mesma empresa
(preferencialmente)
http://dinf.unicruz.edu.br/~plentz/Teste.html www.pucrs.br/inf/eventos2003/workshop/arquivo/MiniCurso_Teste.pdf
Se voc fosse o Gerente de Sistemas de uma empresa como organizaria a sua equipe de desenvolvimento para a tarefa de realizao de testes de software?
64
NIDADE
14
Espiral Dos Testes De Software Objetivo: Apresentar atravs da espiral dos teste de software os principais testes e a sua relao com as etapas de desenvolvimento.
Uma estratgia para teste de software pode tambm ser vista no contexto da espiral da figura anterior. O teste de unidade comea no centro da espiral e se concentra em cada unidade (por exemplo, componente) do software como implementado em cdigo-fonte. O teste progride movendo-se para fora ao longo da espiral para o teste de integrao, em que o foco fica no projeto e na construo da arquitetura do software. Dando outra volta pela espiral para fora, encontramos o teste de validao, em que os requisitos estabelecidos
como parte da anlise dos requisitos do software so validados em contraste com o software que acabou de ser construdo. Finalmente, chegamos ao teste de sistema, em que o software e os outros elementos do sistema so testados como um todo. Para testar o software de computador, nos movemos ao longo da espiral para fora aonde se amplia o escopo do teste a cada volta. A estratgia global pata teste de software orientado a objetos idntica em filosofia que aplicada a arquiteturas convencionais, mas difere na abordagem. Comeamos com o teste no varejo e trabalhamos para fora em direo ao teste por atacado. No entanto, nosso foco quando testando no varejo desloca-se de um mdulo individual (na viso convencional) para uma classe que abrange atributos e operaes e implica comunicao e colaborao. medida que as classes so integradas em uma arquitetura orientada a objetos, uma srie de testes de regresso feita para descobrir erros devidos a comunicao e colaborao entre classes (componentes) e efeitos colaterais causados pela adio de novas classes. Finalmente, o sistema como um todo testado para garantir que erros nos requisitos sejam descobertos.
http://dinf.unicruz.edu.br/~plentz/Teste.html www.pucrs.br/inf/eventos2003/workshop/arquivo/MiniCurso_Teste.pdf
66
Tente refazer a espiral dos testes de software sem olhar o contedo desta unidade. Voc consegue?
67
NIDADE
15
Testes Caixa-Preta E Caixa-Branca Objetivo: Apresentar tcnicas de realizao de testes de software comumente utilizados no mercado. Qualquer produto que passe por engenharia pode ser testado por uma das duas maneiras: Conhecendo-se a funo especificada que o produto foi projetado para realizar, podem ser realizados testes que demonstrem que cada funo est plenamente operacional e, ao mesmo tempo, procurem erros em cada funo. Sabendo-se como o trabalho interno de um produto, podem ser realizados testes para garantir que todas as engrenagens combinem, isto , que as operaes internas sejam realizadas de acordo com as especificaes e que todos os componentes internos foram adequadamente exercitados.
A primeira abordagem de teste chamada de teste de caixa-preta e a segunda, de teste caixa-branca.
SISTEMA Interface do Sistema CAIXA-BRANCA CAIXA-PRETA
68
Teste caixa-preta, ou Teste Funcional, refere-se aos testes que so conduzidos na interface do software. Um teste caixa-preta examina algum aspecto fundamental do sistema, pouco se preocupando com a estrutura lgica interna do software.
Teste caixa-branca de software, tambm chamado de Teste Estrutural, baseado em um exame rigoroso do detalhe procedimental. Caminhos lgicos internos ao software e colaboraes entre componentes so testados, definindo-se caso de testes que exercitam conjuntos especficos de condies e/ou ciclos.
Assim como nos avies, a caixa-preta um teste importante a ser realizado com a parte externa do sistema, ou seja, com a parte que aparece para o usurio: a sua interface. Pelo contrrio, a caixa-branca um teste realizado mais profundamente na parte interna do sistema, aonde um usurio leigo no ter acesso. primeira vista pode parecer que um teste caixa-branca bastante rigoroso levaria a programas 100% corretos. Tudo que precisaramos seria definir todos os caminhos lgicos, desenvolver casos de teste para exercit-los e avaliar os resultados, isto , gerar casos de teste para exercitar a lgica do programa de forma exaustiva. Infelizmente, um teste completo apresenta certos problemas logsticos. Um simples programa com 100 linhas poder facilmente exigir, para a realizao de testes exaustivos, anos de processamento para verificar todas as possibilidades existentes. Um teste caixa-branca no deve, no entanto, ser descartado como no prtico. Um nmero limitado de caminhos lgicos importantes pode ser selecionado e exercitado. Estruturas de dados importantes podem ser submetidas prova quanto sua validade. Uma regra bsica defendida por Boris Beizer que os defeitos juntam-se nos cantos e se congregam nas fronteiras, ou seja, testar os limites do sistema e dentro dos intervalos operacionais. Um exemplo bem prtico desta tcnica de teste o uso da ferramenta livre JUnit para desenvolvimento de classes de teste (test cases) para testar classes ou mtodos desenvolvidos em Java.
A tcnica de teste de Caixa-Branca recomendada para as fases de Teste da Unidade e Teste da Integrao, cuja responsabilidade principal fica ao cargo dos desenvolvedores do software, que por sua vez conhecem bem o cdigo-fonte produzido. A tcnica de teste de Caixa-Preta aplicvel a todas as fases de teste - fase de teste de unidade (ou teste unitrio), fase de teste de integrao, fase de teste de sistema e fase de teste de aceitao. Alguns autores chegam a definir uma tcnica de Teste Caixa Cinza, que seria um mesclado do uso das tcnicas de Caixa Preta e Caixa Branca. Mas, como toda execuo de trabalho relacionado atividade de teste utilizar simultaneamente mais de uma tcnica de teste, recomendvel para que se fixem os conceitos primrios de cada tcnica. Porm, na prtica, o jargo caixa preta ou caixa branca est sendo substitudo por basicamente 3 tipos de tcnicas para realizar testes de software, mais prximas da realidade das equipes envolvidas. So elas: Tcnicas Baseadas em Especificao: Modelos formais ou informais so utilizados para especificao de um problema a ser resolvido, o software ou seu componente. Os casos de testes podem ser derivados sistematicamente destes modelos. Tcnicas baseadas em estrutura: Informaes sobre como o software construdo so utilizadas para derivar os casos de testes. Por exemplo, cdigo e modelagem. A extenso da cobertura de cdigo pode ser medida pelos casos de testes. Alm disso, os casos de testes podem ser derivados sistematicamente para aumentar a cobertura. Tcnicas baseadas em experincia: Conhecimento e experincia de pessoas so utilizados para derivar os casos de testes. Conhecimento sobre defeitos provveis e sua distribuio. Conhecimento de testadores,
70
desenvolvedores, usurios, outros interessados (stakeholders) responsveis pelo software, seu uso e ambiente. A escolha de qual tcnica utilizar depender de uma srie de fatores, incluindo o tipo de sistema, padres, clientes, requisitos contratuais, nvel do risco, tipos de riscos, objetivos do teste, documentao disponvel, conhecimento dos testadores, tempo, dinheiro, ciclo de desenvolvimento, modelo de caso de uso e uma experincia prvia do tipo de defeitos encontrados. O importante que estas tcnicas sejam mescladas ao longo do Ciclo de Desenvolvimento do Sistema, estejam alinhadas a um Processo de Teste bem definido e sejam utilizadas de forma pontual e contnua para garantir a qualidade final do seu sistema.
http://pt.wikipedia.org/wiki/Teste_de_software http://www.timaster.com.br/revista/artigos/main_artigo.asp?codigo=1362
Resuma de forma bem didtica a diferena entre os testes de caixa-preta e os de caixa-branca.
71
NIDADE
16
Mtodos De Teste Orientado A Objetos Objetivo: Diferenciar os testes de software orientado a objetos em relao ao sistemas convencionais. A arquitetura de software orientado a objetos resulta em uma srie de subsistemas em camadas que encapsulam classes de colaborao. Cada um desses elementos do sistema (subsistemas e classes) executa funes que ajudam a satisfazer aos requisitos do sistema. necessrio testar um Sistema OO (Orientado a Objetos) em uma variedade de nveis diferentes para descobrir erros que podem ocorrer medida que classes colaboram umas com as outras e subsistemas se comunicam entre as camadas arquiteturais. Teste orientado a objetos estrategicamente similar ao teste de sistemas convencionais, mas taticamente diferente. Como modelos de anlise e projeto OO so similares na estrutura e no contedo para o programa OO resultante, o teste pode comear com a reviso desses modelos. Uma vez gerado o cdigo, o teste OO real comea no varejo com uma srie de testes projetados para exercitar operaes de classes e examinar se existem erros quando uma classe colabora com outras classes. medida que as classes so integradas para formar um subsistema, o teste baseado no uso, em conjunto com abordagens tolerantes a falhas, aplicado para exercitar completamente as classes que colaboram entre si. Finalmente, Casos de Uso so usados para descobrir erros no nvel de validao do software. Os mtodos de teste caixa-branca, descritos na unidade anterior, podem ser aplicados a operaes definidas para uma classe. Testes mais complexos tais como os de Caminho-
72
base, ou Teste de Ciclos de Fluxos de Dados podem ajudar a garantir que cada declarao em uma operao tenha sido testada. No entanto, a estrutura concisa de muitas operaes de classe faz alguns argumentarem que o esforo aplicado ao teste caixa-branca poderia ser mais bem redirecionado para testes no nvel de classe. Os mtodos de teste caixa-preta so to adequados para Sistemas quanto so para sistemas desenvolvidos usando os mtodos convencionais da Engenharia de Software. Casos de Uso podem fornecer entrada til no projeto de testes caixa-preta e baseados em estado.
Teste Baseado Em Erro O objetivo do teste baseado em erros em um sistema OO projetar testes que tenham uma probabilidade de descobrir erros plausveis. Como o produto ou sistema deve satisfazer aos requisitos do cliente, o planejamento preliminar necessrio para realizar o teste baseado em erros comea com o modelo de anlise. O testador procura erros plausveis, isto , aspectos da implementao do sistema que podem resultar em defeitos, para determinar se esses erros existem, casos de teste so projetados para exercitar o projeto ou o cdigo. Sem dvida, a efetividade dessas tcnicas depende de como os testadores consideram um erro plausvel. Se erros reais em um sistema OO so considerados no plausveis, ento essa abordagem no realmente melhor do que qualquer tcnica de teste aleatrio. No entanto, se os modelos de anlise e projeto puderem fornecer conhecimento aprofundado sobre o que provvel dar errado, ento, o teste baseado em erros pode encontrar um nmero significativo de erros com dispndio de esforo relativamente baixo.
73
O teste de integrao procura erros plausveis na chamada de operaes ou nas conexes de mensagens. Trs tipos de erros so encontrados nesse contexto: 1. Resultado inesperado 2. Uso da operao/mensagem errada 3. Invocao incorreta Para determinar os erros plausveis, quando as funes (operaes) so invocadas, o comportamento da operao deve ser examinado. O teste de integrao se aplica tanto a atributos quanto a operaes. Os comportamentos de um objeto so definidos pelos valores atribudos aos seus atributos. O teste deve exercitar os atributos para determinar se ocorrem valores adequados para os tipos distintos de comportamento do objeto. importante notar que o teste de integrao tenta encontrar erros no objeto cliente, no no servidor. Dito em termos convencionais, o foco do teste de integrao est em determinar se existem erros no cdigo que chama, no no cdigo chamado. A chamada da operao usada como um indcio, um modo de encontrar requisitos de teste que exercitem o cdigo que chama.
Quais so as principais diferenas que devemos tomar ao realizar testes de software baseados em orientao de objetos?
74
NIDADE
17
Projeto De Software De Tempo Real Objetivo: Apresentar tcnicas usadas no projeto de sistemas de tempo real e descrever algumas arquiteturas genricas nesses sistemas. Vamos inicialmente pegar a definio que Sommerville (2007) utiliza para explicar o que so Sistemas de Tempo Real (STR): Um Sistema de Tempo Real um sistema de software cujo funcionamento correto depende dos resultados produzidos pelo sistema e do tempo em que estes resultados so produzidos. A seguir o mesmo Sommerville divide esses sistemas em duas subcategorias: leve e rgido.
Sistema de Tempo Real LEVE (classe A)
Definies
Um Sistema de Tempo Real leve aquele cuja operao ser degradada caso os resultados no sejam produzidos de acordo com os requisitos de timing especficos. Ou ainda, quando o tempo de resposta varivel admissvel. Exemplo: Sistemas on-line como Automao Bancria, reserva de passagem, etc.
RGIDO (classe B)
Um Sistema de Tempo Real rgido aquele cuja operao ser incorreta se os resultados no forem produzidos de acordo com a especificao de timing. Ou seja, quando
75
estimulados por um evento, devem fornecer uma resposta em tempo finito e especificado. Exemplo: Controle e superviso de processos industriais.
Podemos tambm utilizar os interessantes pontos que o Prof. Guedes, da UFRN, explica em suas aulas: O nome de Tempo Real devido ao fato de que a resposta do sistema a uma dada entrada funo do tempo fsico, que externo ao sistema. Nos Sistemas de Tempo Real (STR), a qualidade da resposta do sistema a um dado estmulo funo do tempo externo demandado para esta resposta. A corretude num STR no somente funo da exatido da resposta, mas tambm do tempo necessrio para produzi-la.
76
Para atender a todas as tarefas solicitadas, dentro das suas respectivas restries de tempo, os STR necessitam invariavelmente de alguns mecanismos de gerncia de atividades, classificando-as (ordenando) segundo algum critrio de prioridade de atendimento.
Sistemas Operacionais de Tempo Real (RTOS) Quase todos os sistemas embutidos mais simples funcionam, atualmente, em conjunto com um Sistema Operacional de Tempo Real - RTOS (Real Time Operating System). Um Sistema embutido um computador de propsito especial, normalmente composto por um processador programado para executar tarefas especficas. Eles so encapsulados nos dispositivos por eles controlados. No projeto APOLLO da NASA foi utilizado pela primeira vez um sistema embutido moderno. Como exemplos atuais, temos os seguintes dispositivos que utilizam de sistemas embutidos: celulares, alarme de segurana, cmera de vdeo, calculadoras, impressoras, etc.
Diferenas entre Sistemas Operacionais (OS) e os RTOS Em sistemas embutidos, a aplicao geralmente linkeditada junto com o OS e ela que disparada na inicializao. garantem certa RTOS geralmente no verificam erros da aplicao.
OS toma o controle do sistema na inicializao e dispara as diferentes aplicaes.
OS
tradicionais
proteo contra erros dos aplicativos (ponteiros perdidos) de forma a garantir que os outros aplicativos no sejam afetados.
O Rob motorizado de pesquisa a Marte tem embebido Sistemas Operacionais de Tempo Real
Microprocessador E Microcontrolador interessante apresentar neste momento a diferena bsica entre esse dois dispositivos. O Microprocessador que basicamente utilizado como o processador principal em nossos computadores de propsito geral. J os Microcontroladores so de propsitos especficos, e so utilizados em sistemas embutidos.
No entanto, o prprio Microprocessador precisa de Microcontroladores para ajud-lo a processar nossos dados. Por exemplo, a unidade leitora de CD/DVD constituda basicamente de Microcontroladores com objetivos especficos para aliviar o processamento da CPU principal.
Veja o primeiro captulo do livro Sistemas de Tempo Real de Jean-Marie Farines, Joni da Silva Fraga e Rmulo Silva de Oliveira: http://www.das.ufsc.br/~romulo/livro-tr/cap1.pdf http://www.cs.bu.edu/pub/ieee-rts/Publications.html http://www.dimap.ufrn.br/~jair/dstr/index.html http://pet.inf.ufsc.br/projetos/real-time/index.php?q=home
Visite o interessante material do Prof. Luiz Affonso Guedes, da UFRN, para explorar mais o tema desta unidade: http://www.dca.ufrn.br/ffonso/DCA0409/pdf/str_cap1.pdf OBS.: alguns conceitos e imagens desse material foram aproveitados nesta unidade.
79
NIDADE
18
Engenharia De Software Orientada A Servios Objetivo:. Apresentar os principais conceitos da Engenharia de Software orientada a Servios. As arquiteturas orientadas a servios SOA (Service-Oriented Architectures) so um caminho para o desenvolvimento de sistemas distribudos nos quais os componentes desses sistemas so servios dedicados. Os servios podem ser executados em computadores distribudos geograficamente. Protocolos padronizados foram projetados para apoiar troca de servios de comunicao e de informaes. Um servio pode ser considerado simplesmente como uma abstrao reusvel. Podemos defini-lo, conforme Sommerville, como sendo: Um componente de software reusvel, no firmemente acoplado, que engloba a funcionalidade discreta que pode ser distribuda e acessada por meio de programas. Um Web Service um servio acessado que usa protocolos padres da Internet e baseados em XML.
80
Consequentemente, os servios so plataformas e linguagens de implementao independentes. Sistemas de software podem ser construdos usando servios de provedores diferentes sem nenhuma ligao de interao entre esses servios (Sommerville, 2007). Na figura a seguir vemos como os Web services funcionam. Os provedores de servios projetam e implementam servios e os especificam em uma linguagem chamada WSDL. Eles tambm publicam informaes sobre esses servios em um registro de acesso geral usando um padro de publicao chamado UDDI. Os solicitantes de servios (algumas vezes chamados de clientes de servios), que desejam fazer uso de um servio, buscam o registro UDDI para descobrir a especificao desse servio e para localizar um provedor de servios. Eles podem ento unir as suas aplicaes para um servio especfico e se comunicar com ele, usando geralmente um protocolo chamado de SOAP. Em outras palavras podemos dizer que a arquitetura Orientada a Servios pode ser bem representada a partir do seguinte processo, chamado de "find-bind-execute paradigm" o que significa aproximadamente paradigma de "procura-consolida-executa". Tal conceito anlogo a "Ciclo de Deming" aplicado aos servios, que define o ciclo que envolve o planejamento, a execuo, o monitoramento e a tomada de ao proativa para a melhoria da qualidade. Tecnicamente falando, o processo preconiza que os provedores de servios registrem informaes em um registro central, com suas caractersticas, indicadores, e aspectos relevantes s tomadas de decises. O registro utilizado pelo cliente para determinar as caractersticas dos servios necessrios, e se o mesmo estiver disponvel no registro central, como por exemplo, por um catlogo de servios, o cliente poder utiliz-lo, sendo este oficializado atravs de um contrato que enderece este servio.
81
Resumidamente, os padres principais das arquiteturas orientadas a servios so: SOAP (Simple Object Access Protocol): um padro de troca de mensagens que d suporte comunicao entre servios. Ele define os componentes essenciais e opcionais das mensagens passadas entre servios. WSDL (Web Service Definition Language): o padro de linguagem de definio de servio Web estabelece o meio pelo qual os provedores de servios devem definir a interface para esses servios. Essencialmente, ele permite que a interface de um servio (operaes de servios, parmetros e seus tipos) e suas ligaes sejam definidas de maneira padronizada. UDDI (Universal Description, Discovery and Integration): O padro de descrio, descoberta e integrao universal define os componentes de uma especificao de servios que pode ser usada para descobrir a existncia de um servio. Esses componentes incluem informaes sobre o provedor de servios, os servios fornecidos, a localizao da descrio de servios (usualmente expressa em WSDL) e informaes sobre relacionamentos de negcio. O UDDI registra os usurios potenciais de um servio capazes de descobrir quais servios esto disponveis.
82
http://pt.wikipedia.org/wiki/Service-oriented_architecture http://pt.wikipedia.org/wiki/Simple_Object_Access_Protocol http://www.abepro.org.br/biblioteca/ENEGEP2007_TR670485_9968.pdf http://cio.uol.com.br/tecnologia/2006/07/17/idgnoticia.2006-07-17.3732358054/
Explique em poucas palavras os princpios bsicos das arquiteturas orientadas a servios.
83
NIDADE
19
Engenharia De Servios Objetivo: Apresentar os estgios lgicos no processo de engenharia de servios A Engenharia de Servios o processo de servios de desenvolvimento para reuso nas aplicaes orientadas a servios. Ela tem muito em comum com a engenharia de componentes. Os engenheiros de servios tm que assegurar que o servio representa uma abstrao reusvel que poderia ser til em diferentes sistemas. Os engenheiros de servios devem projetar e desenvolver geralmente funcionalidades teis associadas com essas abstraes e devem assegurar que o servio seja robusto e confivel de modo a operar confiavelmente em diferentes aplicaes. Tm de documentar o servio de modo que possa ser descoberto e compreendido por usurios potenciais. H trs estgios lgicos no processo de engenharia de servios. So eles: 1. Identificao do servio candidato em que voc identifica possveis servios que poderiam se implementados e define os requisitos do servio. 2. Projeto do servio no qual voc projeta a lgica e as interfaces de servios WSDL. 3. Implementao e implantao do servio em que voc implementa e testa o servio, e o faz disponvel para o uso.
84
Identificao Identificaode de servio candidato servio candidato
Projeto Projeto de deinterface interface do doservio servio
Implantao Implantaoe e implementao implementao do doservio servio
Requisitos Requisitos do doservio servio
Especificao Especificao de deinterface interface do doservio servio
Servio Servio implantado implantado e evalidado validado
Identificao De Servio Candidato A noo bsica da computao orientada a servios que os servios devem apoiar os processos de negcios. Como toda organizao tem grande quantidade de processos h, portanto, muitos servios possveis que podem ser implementados. A identificao do servio candidato envolve compreenso e anlises dos processos de negcios da organizao, para decidir quais servios reusveis so necessrios para apoiar os processos.
Erl identifica trs tipos fundamentais de servio que podem ser identificados: SERVIO de UTILIDADES: So servios que implementam algumas funcionalidades gerais que podem ser usadas por diferentes processos de negcios. Por exemplo, converso de moedas. SERVIO de NEGCIOS: So servios associados com uma funo especfica de negcio. Por exemplo, numa universidade o registro de estudantes.
85
SERVIO de COORDENAO ou de PROCESSO: So servios que apoiam os processos de negcio mais gerais que envolvem diferentes atores e atividades. Um exemplo seria o servio de pedidos a serem feitos para fornecedores, mercadorias aceitas e pagamentos feitos.
Projeto De Interface Do Servio Uma vez selecionados os servios candidatos, o prximo estgio no processo da Engenharia de Servio projetar as interfaces dos servios. Deve-se pensar tambm cuidadosamente sobre como as operaes e as mensagens de servio podem ser projetadas para minimizar o nmero de troca de mensagens que ocorrerem para completar a solicitao de servio.
H trs estgios para o projeto de interface de servio: 1. Projeto de interface lgica no qual se identificam as operaes associadas com o servio, as entradas e as sadas dessas operaes e as excees associadas com essas operaes. 2. Projeto de mensagem no qual se projeta a estrutura das mensagens enviadas e recebidas pelo servio. 3. Desenvolvimento WSDL no qual se traduz o projeto lgico e de mensagem para uma descrio abstrata de interface escrita em WSDL.
Implementao E Implantao De Servio Uma vez identificados os servios candidatos e projetadas as interfaces, o estgio final do processo de Engenharia de Servios a implementao do servio. Essa implementao pode envolver a programao dos servios usando uma linguagem padronizada de
86
programao, como Java ou C#. Ambas as linguagens atualmente incluem bibliotecas com apoio extensivo para desenvolvimento de servios. A implantao do servio, o estgio final do processo, envolve tornar o servio disponvel para o uso no servidor Web. Muitos softwares de servidores tornam isso muito simples. Temse somente que instalar o arquivo que contm o servio executvel num diretrio especfico. Ento, torna-se automaticamente disponvel para o uso. Se a inteno for disponibilizar o servio publicamente, tem-se de escrever uma descrio UDDI para que os usurios potenciais possam achar o servio. H atualmente um nmero de registros pblicos para descries UDDI e os negcios podem tambm manter o registro privado de UDDI. Uma descrio UDDI consiste em um nmero de diferentes tipos de informao: Detalhes dos negcios que fornecem o servio. Isso importante por motivos de confiabilidade. Usurios de um servio tm de ser confiveis no sentido de que no tero comportamento malicioso. As informaes sobre o provedor dos servios permitem aos usurios verificarem as credenciais do provedor. Descrio informal das funcionalidades fornecidas pelo servio. Auxilia os usurios potenciais a decidirem se o servio o que eles desejam. No entanto, a descrio funcional uma linguagem natural, portanto ela no uma descrio semntica e sem ambiguidade do que o servio faz. Informaes sobre onde encontrar a especificao WSDI associada ao servio Informaes de assinatura Permitem aos usurios se registrarem para obter informaes sobre atualizaes de servios.
87
http://wnews.uol.com.br/site/noticias/materia_especial.php?id_secao=17&id_conteu do=425 http://apconcursos.blogspot.com/2007/05/desenvolvimento-soa.html
Realize uma sntese desta unidade com o objetivo de gerar os passos principais na Engenharia de Servios.
88
NIDADE
20
Desenvolvimento De Software Orientado A Aspectos Objetivo: apresentar o desenvolvimento de software orientado a aspectos, que baseado na ideia de separao de assuntos em mdulos de sistema separados O desenvolvimento de software orientado a aspectos - AOSD (Aspect-Oriented Software Development) uma abordagem emergente para desenvolvimento de software com a inteno de resolver o problema do reuso de componentes, pois, devido a eles no implementarem uma nica abstrao de sistema, mas tambm inclurem fragmentos de cdigo que implementam outros requisitos. O AOSD baseado em torno de um novo tipo de abstrao chamado de aspecto. Aspectos so usados junto com outras abstraes como objetos e mtodos. Eles englobam funcionalidades que atravessam e coexistem com outras funcionalidades includas no sistema. O benefcio principal de uma abordagem orientada a aspectos que ela apoia a separao de assuntos. A separao de assuntos em elementos independentes no lugar de incluir diferentes assuntos numa mesma abstrao lgica uma boa prtica de engenharia de software. A separao de assuntos o principal princpio do projeto e da implementao de software. Essencialmente, ele significa que voc deve organizar o seu software de modo que cada elemento no programa (classe, mtodo, procedimento, etc.) faa uma coisa e somente uma coisa. Pode-se compreender cada parte do programa pelo conhecimento do seu assunto, sem necessitar entender outros elementos. Quando so necessrias mudanas, elas esto localizadas em um pequeno nmero de elementos. Embora se concorde geralmente com que a separao de assuntos uma boa prtica de engenharia de software, difcil definir qual o significado real de um assunto. Algumas
vezes, ele definido como uma noo funcional na qual um assunto algum elemento funcional do sistema; alternativamente, ele pode ser definido de maneira mais abrangente como alguma parte de interesse ou foco de um programa. Um assunto , portanto, algo de interesse ou significativo para um stakeholder ou para um grupo de stakeholders. Com essa viso de um assunto, vemos ento por que uma abordagem para implementao que separa assuntos em diferentes elementos de programa uma boa prtica. mais fcil rastrear assuntos, definidos como requisito ou conjunto de requisitos relacionados e os componentes de programa que implementam esses assuntos. Se os requisitos mudam (e mudam constantemente !), a parte do programa que precisa ser mudada obvia.
Existem muitos tipos diferentes de assuntos de stakeholders: Assuntos funcionais Relacionados a uma funcionalidade especfica a ser includa em um sistema. Por exemplo, num sistema de controle de trens, um assunto funcional especfico o freio do trem. Assuntos de qualidade de servio Que esto relacionados ao ambiente no funcional de um sistema. Esses assuntos incluem caractersticas como desempenho, confiabilidade e disponibilidade. Assuntos de poltica Relacionados s polticas gerais que governam o uso do sistema. Assuntos de poltica incluem assuntos de proteo e segurana e assuntos relacionados s regras de negcio. Assuntos de sistema Relacionados aos tributos do sistema como um todo, como sua facilidade de manuteno e de configurao.
90
Assuntos organizacionais Relacionados aos objetivos e s prioridades organizacionais como a produo de um sistema dentro do oramento, o uso de ativos de software existentes ou a manuteno de reputao da organizao. Assuntos de sistema Aplicam-se ao sistema como um todo em vez de requisitos individuais ou realizao dos requisitos em um programa. A esses assuntos secundrios chamamos de transversais para distingui-los de assuntos centrais. Veja na figura abaixo os conceitos anteriores com um exemplo de um sistema bancrio de Internet.
NOVOS REQUISITOS DE CLIENTES
REQUISITOS DE CONTAS
REQUISITOS DE GERENCIAMENTO DE CLIENTES
ASSUNTOS TRANSVERSAIS Requisitos Requisitosde deproteo proteo
Requisitos Requisitosde derecuperao recuperao
ASSUNTOS CENTRAIS
91
http://www.webartigos.com/articles/1954/1/Projeto-de-Software-Orientado-aAspectos/Pagina1.html http://twiki.cin.ufpe.br/twiki/pub/SPG/GenteAreaPublications/SBES04_soares.pdf http://aspect-oriented.awardspace.com/desvpoa.html
Realize uma pesquisa na Web sobre os locais em que est sendo aplicada a tecnologia AOSD.
Antes de dar continuidades aos seus estudos fundamental que voc acesse sua SALA DE AULA e faa a Atividade 2 no link ATIVIDADES.
92
NIDADE
21
Engenharia De Software Com Aspectos Objetivo: Conceituar os princpios da Engenharia de Software com Aspectos. Os aspectos foram inicialmente introduzidos como uma construo de linguagem de programao, o conceito de assuntos vem de requisitos de sistema. Portanto, faz sentido adotar uma abordagem orientada a aspectos em todos os estgios do processo de desenvolvimento de sistema. Nos estgios iniciais de Engenharia de Software, a adoo de uma abordagem orientada a aspectos significa usar o conceito de separao de assuntos como base para pensar em requisitos e o projeto de sistemas. A identificao e a modelagem de assuntos devem ser parte dos processos de engenharia de requisitos e projeto. As linguagens de programao orientada a aspectos fornecem, portanto, o apoio tecnolgico para manter a separao de assuntos na sua implementao do sistema. Jacobsen e Ng (2004) em seu livro Aspect-oriented software development with use cases sugerem que se deva pensar num sistema que apoie diferentes assuntos envolvidos como um sistema central mais extenses. Na figura a seguir atravs de packages UML so representadas essas ideias representando tanto o centro quanto as extenses. O sistema central o conjunto de caractersticas de sistema que fornecem apoio para o propsito essencial do sistema.
93
Extenso 2
Extenso 1
Extenso 3
Sistema Central
Extenso 4
Extenso 6
Extenso 5
Portanto, se o propsito do sistema manter a informao de pacientes em um hospital, o sistema fornece um meio para criar, editar, gerenciar e acessar um banco de dados de registros de pacientes. As extenses para o Sistema Central refletem assuntos adicionais dos stakeholders do sistema que devem ser integrados com o sistema central. Por exemplo, importante que o sistema de informao de hospital mantenha a confidencialidade de informaes de pacientes e, assim, uma extenso possa ser dedicada ao controle de acesso, outra criptografia, etc. H uma quantidade de tipos de extenses derivadas de diferentes tipos de assuntos: EXTENSES FUNCIONAIS SECUNDRIAS: Essas extenses adicionam capacidades funcionais para funcionalidades fornecidas no Sistema Central. Por exemplo, a produo de relatrios de medicamentos prescritos no ms anterior seria uma extenso funcional secundria para um sistema de informao de pacientes. EXTENSES DE POLTICAS:
Essas extenses adicionam capacidades funcionais para apoiar algumas polticas organizacionais. Extenses que adicionam caractersticas de proteo so exemplos de extenses de polticas. EXTENSES de QoS (Quality of Service): Essas extenses adicionam capacidades funcionais para auxiliar a atender os requisitos da qualidade de servio QoS que forem especificados para o sistema. Por exemplo, uma extenso poderia fornecer apoio a um cach para reduzir o nmero de acessos ao Banco de Dados ou a back-ups automticos para se recuperar no evento de uma falha de sistema. EXTENSES DE INFRA-ESTRUTURA: Essas extenses adicionam capacidades funcionais para dar suporte implementao de um sistema em alguma plataforma especfica. Por exemplo, em um sistema de informao de pacientes, as extenses de infraestrutura poderiam ser usadas para implementar a interface para o sistema de gerenciamento de Banco de Dados. Se isso mudar, as mudanas podero ser feitas por meio da alterao de extenses de infraestrutura associadas.
As extenses adicionam sempre algum tipo de funcionalidade ou caractersticas para o Sistema Central. Aspectos so um meio para implementar as extenses e podem ser compostos com a funcionalidade do Sistema Central usando os recursos de composio no ambiente de programao orientado a aspectos.
Quais so os tipos de extenses derivadas de diferentes tipos de assuntos apresentadas nesta unidade?
95
NIDADE
22
Estimativa De Custo De Software Objetivo: apresentar tcnicas de estimativa de custo e esforo necessrios para a produo de software. A estimativa de recursos, de custo e de cronograma para um esforo de engenharia de software exige experincia, acesso a boas informaes histricas (mtricas) e coragem de se empenhar em previses quantitativas, quando informao qualitativa tudo que existe. Estimativa tem risco inerente e esse risco leva incerteza. Sempre que so feitas estimativas, olhamos para o futuro e aceitamos algum grau de incerteza como inevitvel. Apesar de estimar ser tanto arte como cincia, essa importante atividade no precisa ser conduzida de modo aleatrio. J existem tcnicas teis para estimativa de tempo e esforo. Mtricas de processo e projeto podem fornecer perspectiva histrica e insumo poderoso para a gerao de estimativas quantitativas. Experincia anterior, de todo o pessoal envolvido, pode ajudar imensamente, medida que estimativas so desenvolvidas e revistas. Como a estimativa estabelece uma base para todas as outras atividades de planejamento de projeto e como este fornece um guia para a engenharia de software bem-sucedida, seria temerrio comear sem ela.
A disponibilidade de informao histrica tem forte influncia no risco da estimativa. Olhando para trs, podemos imitar coisa que funcionaram e aperfeioar reas em que surgiram problemas. Quando mtricas de software abrangentes, oriundas de projetos anteriores, esto
96
disponveis, as estimativas podem ser feitas com maior segurana, os cronogramas podem ser estabelecidos para evitar dificuldades enfrentadas antes e o risco global reduzido. O risco da estimativa medido pelo grau de incerteza das estimativas quantitativas estabelecidas para recursos, custo e tempo. Se o escopo do projeto mal entendido ou se os requisitos esto sujeitos a mudanas, a incerteza e risco tornam-se perigosamente altos. O planejador e, principalmente, o cliente devem reconhecer que variabilidade nos requisitos de software significa instabilidade no custo e no cronograma. O objetivo do planejamento de projeto fornecer um arcabouo que permita ao gerente fazer estimativas razoveis de recursos, custo e cronograma. Alm disso, as estimativas devem tentar definir cenrios (positivos e negativos) correspondentes tanto ao melhor quanto ao pior caso, de modo que o comportamento do projeto possa ser delimitado. Assim, o plano deve ser adaptado e atualizado medida que o projeto avanar. Conforme Pressman (2006), sugere-se um conjunto de tarefas para o devido planejamento do projeto quanto s estimativas de custo do software:
Estabelea o escopo do projeto Determine a viabilidade Analise riscos Defina recursos necessrios Determine recursos humanos necessrios Defina recursos reusveis de software Identifique os recursos que o ambiente oferece Estime custo e esforo
97
Decomponha o problema Desenvolva duas ou mais estimativas usando tamanho, ponto por funo, tarefas de processo, ou casos de uso
Harmonize as estimativas Desenvolva um Cronograma do Projeto Estabelea um conjunto significativo de tarefas Defina uma rede de tarefas a serem realizadas Use ferramentas para desenvolver um diagrama de tempo Defina mecanismos de rastreamento do cronograma
http://www.consiste.dimap.ufrn.br/~claudia/Mestrado/Disciplinas/Engenharia_Softw are/Artigo%5B6%5D_Estimativas.pdf http://sunset.usc.edu/research/cocomosuite/index.html http://www.linhadecodigo.com.br/Artigo.aspx?id=102 http://www.inf.ufrgs.br/pos/SemanaAcademica/Semana99/mariaisabel/mariaisabel. html
98
Faa uma anlise crtica do conjunto de tarefas sugerido por Pressman para o devido planejamento do projeto quanto s estimativas de custo do software.
99
NIDADE
23
Mtricas Para Pequenas Organizaes Objetivo: Apresentar possveis formas de trabalhar com mtricas num pequena organizao Medio uma ferramenta de gesto. Se conduzida adequadamente, fornece conhecimentos a um gerente de projeto. E, como resultado, apia o gerente de projeto e a equipe de software na tomada de decises que iro conduzir a um projeto de sucesso. Medio pode ser aplicada ao processo de software com o objetivo de melhor-lo de forma contnua.
No livro de diretrizes sobre medio de software, Park, Goethert e Florac (1996) discutem as razes pelas quais medimos: Para caracterizar um esforo a fim de obter entendimento de processos, produtos, recursos e ambientes, e para estabelecer referncias para comparao com futuras avaliaes. Para avaliar a fim de determinar o estado em relao aos planos. Para prever pela obteno de entendimento de relacionamentos entre processos, produtos e construo de modelos desses relacionamentos. Para aperfeioar pela identificao de bloqueios, causas fundamentais, ineficincias e outras oportunidades para melhorar a qualidade do produto e o desempenho do processo.
100
A grande maioria das organizaes de desenvolvimento possui menos de 20 profissionais de software. irracional, e, na maior parte dos casos, invivel esperar que essas organizaes desenvolvam programas abrangentes de mtricas de software.
Todavia, razovel sugerir que organizaes de software de todos os tamanhos meam e depois usem as mtricas resultantes para ajudar a aperfeioar seu processo local de software, e a qualidade e pontualidade dos produtos que produzem. A atividade de medir ajuda aos gerentes e componentes da equipe a melhorar o processo de desenvolvimento de software. Para calcular as mtricas so utilizadas medies de atributos especficos do processo, projeto e produto. As mtricas permitem a organizao a ter uma viso estratgica, oferecendo informaes sobre o processo de software. Medio resulta em uma mudana na cultura da empresa. Uma abordagem de bom senso para a implementao de qualquer atividade relacionada a processo de software seria: Que seja simples; Ajuste s necessidades locais; e
Certificar-se de que tenha valor.
A simplicidade uma diretriz que funciona razoavelmente bem em muitas atividades. Contudo, como originarmos um conjunto de mtricas de software simples, que ainda mesmo assim tenha valor, e como podemos estar certos de que essas mtricas simples vo satisfazer s necessidades da minha organizao?!? A chave comearmos focalizando no a medio, mas os resultados!! O grupo de software interrogado para definir um nico objetivo que requer aperfeioamento. Por exemplo, reduza o prazo para avaliar e implementar pedidos de modificao. Para este caso especfico, uma pequena empresa poderia selecionar o seguinte conjunto de medidas facilmente coletveis: tfila TEMPO (horas ou dias) transcorrido entre o momento em que o pedido feito at que a avaliao esteja completa. W aval ESFORO (homem/hora - h/h) para realizar a avaliao. taval TEMPO (horas ou dias) transcorrido desde o trmino da avaliao at a atribuio da ordem de modificao ao pessoal. W mod ESFORO (homem/hora - h/h) necessrio para fazer a modificao. tmod TEMPO (horas ou dias) necessrio para fazer a modificao. Emod ERROS descobertos durante o trabalho para fazer a modificao. Dmod DEFEITOS descobertos depois que a modificao entregue ao cliente.
Com base nesses dados coletados, para certo nmero de pedidos de modificao, possvel calcular: O tempo total transcorrido desde o pedido at a implementao da modificao; Porcentagem do tempo transcorrido, absorvida pelo escalonamento inicial, avaliao, atribuio e implementao da modificao;
Porcentagem do esforo necessrio para avaliao e implementao.
Ou seja, os percentuais de tempo gastos em cada fase so determinados e, ento, podem ser melhorados. Essas mtricas podem ser avaliadas no contexto dos dados de qualidade Emod e Dmod. As porcentagens permitem discernir onde o processo do pedido de modificao sofre demora, e podem levar a passos de melhoria do processo para reduzir tfila , W aval , taval , W mod , e/ou Emod . Alm disso, a eficincia na remoo de defeitos pode ser calculada como: DRE = Emod / (Emod + Dmod ) DRE pode ser comparada com o tempo transcorrido e o esforo total para determinar o impacto das atividades de garantia pelo tempo e o esforo necessrios para fazer uma modificao. As vantagens so muito grandes, alm de que o custo, no incio, de coletar medidas da ordem de 3 a 8% do oramento do projeto, e cai para 1% depois que a equipe comea a se familiarizar e ver os benefcios dessas medidas.
Estabelecendo Um Programa De Mtricas O Software Engineering Institute - SEI desenvolveu um manual de diretrizes abrangentes para estabelecer um programa de mtricas de software orientado a metas, que sugere os seguintes passos: Identifique as metas do seu negcio Identifique o que voc necessita conhecer ou aprender Identifique suas submetas Identifique as entidades e atributos relacionados s suas submetas Formalize suas metas de medio
Identificar as perguntas e os indicadores desejados Identificar os elementos de dados requeridos Definir a medidas a serem feitas e torn-las operacionais Identifique as aes a serem executadas para implementar as medidas Prepare um plano para implementar as medies
http://pt.wikipedia.org/wiki/M%C3%A9tricas_de_software www.des.ime.eb.br/~cgmello/gep/4-GEP-Metricas.pdf
Realize uma pesquisa na sua empresa, ou na de colegas, e verifique quais so as mtricas adotadas pela rea de sistemas.
104
NIDADE
24
Estimativa Do Projeto De Software Objetivo: apresentar tcnicas de estimativa de custo e esforo necessrios para a produo de software. A estimativa de custo e de esforo de software nunca ser uma cincia exata. Um demasiado nmero de variveis humanas, tcnicas, ambientais, polticas podem afetar o custo final do software e o esforo aplicado para desenvolv-lo. Todavia, a estimativa de projetos de software pode ser transformada de algo sobrenatural em uma srie de passos sistemticos que fornecem estimativas com risco aceitvel. Algumas das opes para conseguir estimativas de custo e esforo confiveis so: Adie a estimativa at que o projeto esteja o mais adiantado. Baseie as estimativas em projetos semelhantes, que j foram completados. Use tcnicas de decomposio relativamente simples para gerar estimativas de custo e esforo do projeto. Use um ou mais modelos empricos para estimativa de custo e esforo do software.
Tcnicas de decomposio usam a abordagem dividir para conquistar para a estimativa de projetos de software. Pela decomposio de um projeto em suas funes principais e atividades relacionadas de engenharia de software, a estimativa de custo e esforo pode ser realizada passo a passo. Modelos empricos de estimativa podem ser usados para complementar as tcnicas de decomposio e oferecem por si mesmos uma valiosa abordagem de estimativa.
105
Tcnicas De Decomposio A estimativa de projeto boa na mesma medida em que o a estimativa do tamanho do trabalho a ser realizado, o dimensionamento representa o primeiro grande desafio do planejador do projeto. O tamanho do software a ser construdo pode ser estimado usando uma medida direta (LOC Linhas de Cdigo), ou uma medida indireta (FP Pontos de Funo). As estimativas LOC e FP so tcnicas distintas. Todavia, ambas tm algumas caractersticas em comum. O planejador do projeto comea com uma declarao delimitada do escopo do software e a partir dela tenta decompor o software em funes do problema que podem ser estimadas individualmente. LOC ou FP, a varivel de estimativa, ento estimada para cada funo. Como alternativa, o planejador pode escolher outro componente para dimensionar, como classes ou objetos, modificaes ou processos do negcio diretamente afetados. Uma vantagem dos PF sobre as LOC que os Pontos de Funo podem ser obtidos logo no incio do ciclo de vida, diretamente dos requisitos ou especificaes. Os PF so teis para estimativas independentes de linguagem, realizadas no incio do ciclo de vida. Por outro lado, a utilizao das LOC na previso do esforo total de um projeto continua tendo sucesso para uma ampla quantidade de projetos, envolvendo diversas linguagens. Embora Casos de Uso forneam a uma equipe de software discernimento do escopo e requisitos do software, desenvolver uma abordagem de estimativa com Casos de Uso problemtico pelas seguintes razes: Casos de Uso so descritos usando muitos formatos e estilos diferentes (no h um formato padro). Casos de Uso representam uma viso externa (a viso do usurio) do software e so frequentemente escritos em diferentes nveis de abstrao.
106
Casos de Uso no tratam da complexidade e das caractersticas das funes que so descritas.
Casos de Uso no descrevem comportamentos complexos (por exemplo, interaes) que envolvem muitas funes e caractersticas.
Diferentemente de uma LOC ou FP, um caso de uso de uma pessoa pode precisar meses de esforo, enquanto um caso de uso de outra pessoa pode ser implementado em um ou dois dias. Modelos De Estimativa Empricos Os dados empricos que apoiam a maioria dos modelos de estimativa so derivados de uma amostra limitada de projetos. Por esse motivo, nenhum modelo de estimativa adequado a todas as classes de software e a todos os ambientes de desenvolvimento. Assim, os resultados obtidos de tais modelos devem ser usados cuidadosamente. Um modelo de estimativa tpico derivado usando anlise de regresso de dados coletados em projetos de software anteriores. Um modelo de estimativa deve ser calibrado para refletir as condies locais. O modelo deve ser testado aplicando os dados coletados de projetos j finalizados, ligando os dados ao modelo, e depois comparando os resultados reais com os previstos. Se a concordncia for baixa, o modelo dever ser sintonizado e retestado antes que possa ser usado.
www.cefetrn.br/~placido/disciplina/pgp/aulas/Metricas.pdf
107
Quais so as principais diferenas existentes entre os conceitos de LOC e FP ?
108
NIDADE
25
Modelo De Estimativa De Software Cocomo Ii Objetivo: Conceituar o modelo clssico de estimativa de software. Em seu livro clssico sobre a Economia da Engenharia de Software, Barry Boehm (1981), introduziu uma hierarquia de modelos de estimativa de software denominada COCOMO COnstructive COst MOdel, que significa modelo construtivo de custo. O modelo COCOMO original tornou-se um dos modelos de estimativa de custo de software mais amplamente usado e discutido na indstria. um mtodo que busca medir esforo, prazo, tamanho de equipe e custo necessrio para o desenvolvimento do software, desde que se tenha a dimenso do mesmo, atravs de um modelo de estimativa de tamanho de software, como Anlise de Pontos de Funo. Evoluiu para um modelo de estimativa mais abrangente, chamado de COCOMO II, verso publicada em 2000.
O Modelo COCOMO II foi originalmente calibrado com dados de 161 projetos. Os
109
mesmos foram selecionados dentre mais de 2000 projetos candidatos. Para cada um dos 161 projetos escolhidos foram realizadas entrevistas e visitas, a fim de garantir a consistncia das definies e suposies do modelo. O modelo nominal vem calibrado para esses projetos, cuja natureza pode diferir daquele que se deseja estimar. Como seu predecessor, o COCOMO II na verdade uma hierarquia de modelos de estimativa que tratam das seguintes reas: Modelo de composio da aplicao: Usado durante os primeiros estgios da Engenharia de Software, quando a prototipagem das interfaces com o usurio, a considerao da interao do software com o sistema, a avaliao do desempenho e o julgamento da maturidade tecnolgica so de extrema importncia. Modelo do primeiro estgio de projeto: Usado aps os requisitos terem sido estabilizados e a arquitetura bsica do software ter sido estabelecida. Modelo para o estgio aps a arquitetura: Usado durante a construo do software.
Os objetivos do COCOMO II foram definidos para suportar as necessidades primrias da estimativa de custo, devendo fornecer suporte para a etapa de planejamento de projetos, equipe de desenvolvimento necessria, preparao inicial do projeto, replanejamento, negociao de contratos, avaliaes de propostas, necessidades e nveis de recursos (tecnolgicos e humanos). Como todos os modelos para estimativa de software, o modelo COCOMO II requer informao de tamanho. Trs diferentes opes de dimensionamento esto disponveis como partes da hierarquia de modelos:
1. Pontos por objeto 2. Pontos por funo 3. Linhas de cdigo-fonte Para o clculo do custo deve-se conhecer o prazo e equipe de trabalho, para ento chegar ao valor, sendo que para definir o tamanho do programa, torna-se necessrio que se caracterize que medida ser adotada: linhas de cdigo, pontos por funo ou pontos por caso de uso (o menos adequado !). O CoCoMo II estima o custo e tempo baseado em pessoas/ms e meses, para a determinao do baseline de exigncias de um produto para a concluso de uma atividade. Define-se baseline como o conjunto de produtos aceitos e controlados, e que sero utilizados em atividades posteriores sua aceitao. O modelo ainda prev um adicional de 20% ao tempo computado, como margem de erro (anlise de risco). Embora o CoCoMo II possa ser executado com os parmetros nominais, pressupe-se a calibrao para o ambiente-alvo. Com a calibrao em projetos do mesmo ramo possvel modificar o valor das constantes das frmulas padres. Na ausncia de dados histricos disponveis para o ambiente-alvo em questo, devem ser selecionados projetos equivalentes para efetuar a calibrao. Devido ao seu impacto exponencial, no recomendvel calibrar o modelo quando houver menos de 10 projetos disponveis para a calibrao, conforme Boehm (2000).
111
http://pt.wikipedia.org/wiki/M%C3%A9todo_COCOMO http://en.wikipedia.org/wiki/COCOMO www.ulbra-to.br/ensino/43020/artigos/anais2005/anais/COCOMO.pdf www.bfpug.com.br/islig-rio/Downloads/Estimando_Projetos_COCOMO_II.pdf
Visite o site http://sunset.usc.edu/research/COCOMOII/cocomo_main.html e relacione as principais caractersticas do software de apoio ao modelo.
112
NIDADE
26
Engenharia De Software Para A Web Objetivo: Apresentar as principais caractersticas da Engenharia de Sofware para a Web. Sistemas e aplicaes baseados na Web, tambm chamados de WebApps, englobam desde uma simples pgina Web com recursos de interao com o usurio, at um abrangente site fornecedor de servios completos para toda uma comunidade especfica de internautas. Atualmente as WebApps evoluram tanto com ferramentas computacionais sofisticas que no fornecem somente funes isoladas para o usurio final, mas tambm so integradas com banco de dados coorporativos e aplicaes de negcio (Pressman, 2006). As aplicaes na Internet, em sua grande maioria, possuem os seguintes atributos: CONCENTRAO em REDES: Necessariamente uma WebApp reside numa rede para atender uma comunidade diversificada de usurios. Existe a possibilidade de essa aplicao rodar tanto na prpria Internet, que o mais comum, como numa Intranet e nas Extranets. No caso da Intranet essas aplicaes facilitam o processo de integrao e comunicao dentro das organizaes, e no caso da Extranet para aprimorar o relacionamento com os seus parceiros (fornecedores, clientes, distribuidores, etc.).
CONCORRNCIA: Qualquer WebApp que tenha muitos usurios ter o problema de ser acessada simultaneamente ao mesmo tempo. Inclusive com a possibilidade de ataques do tipo denialof-service (DoS) por hackers, com o intuito de impedir que um usurio legtimo utilize um determinado servio.
CARGA IMPREVISVEL: Embora seja bastante difcil, em certas aplicaes, de dimensionar a quantidade de usurios que acessaro os servios, existe a necessidade de controlar constantemente a carga dos servidores. Se a aplicao no for bem dimensionada e proporcional demanda dos usurios, pode ocorrer inclusive travamento do servidor. Novamente um ataque por hackers pode camuflar todas as estatsticas de acesso.
DESEMPENHO: O tempo de resposta da aplicao Web tem que ser muito bem avaliada. Se os usurios so clientes de um servio que facilmente encontrar em outro site, ocorrer uma grande evaso se os tempos de resposta forem muito longos e decorrero reclamaes em quantidade.
DISPONIBILIDADE: A grande maioria dos provedores trabalha com a metodologia 6 sigma, tentando atingir a disponibilidade de 4 dgitos depois da vrgula, pois dificilmente chegaremos a 100% de disponibilidade. Veja na tabela a seguir que cada vez que avanamos numa casa decimal, o impacto das horas fora do ar (off-line), em um ano, decresce significativamente.
O uso da Internet est to disseminado que o sonho dos usurios a base de 24 / 7 / 365 (24 horas por dia, 7 dias na semana, 365 dias no ano !!).
114
ORIENTADA a DADOS: Embora a funo principal de muitas WebApps sejam de usar os recursos de hipermdia (texto, grficos, udio, vdeo) ao usurio final, atualmente muito comum elas acessarem grandes Bancos de Dados. Um exemplo tpico o e-commerce e as aplicaes financeiras.
SENSVEL ao CONTEDO: Um bom exemplo desse aspecto o prprio Google. Se as vrias ferramentas desse mecanismo de busca no fossem to significativas em termo de contedo para os usurios, essa empresa no teria a projeo que tem hoje.
EVOLUO CONTINUADA: Uma das premissas da atual Web 2.0 o beta teste eterno, ou seja, a primeira verso do aplicativo liberada aos usurios e mesmo assim continuar recebendo melhorias constantes ao longo do projeto. As aplicaes Web evoluem continuamente.
115
IMEDIATISMO: freqente que as aplicaes da Internet tenham que estar disponibilizadas para os usurios em questes de semanas ou mesmo em dias. Portanto, os engenheiros Web precisam usar mtodos de planejamento, anlise, projeto, implementao e teste especiais conforme as exigncias do desenvolvimento de WebApp.
SEGURANA: A fim de proteger contedo reservado e fornecer modos seguros de transmisso de dados, fortes medidas de segurana precisam ser implementadas em toda a infraestrutura que apoia uma WebApp e na aplicao propriamente dita. A nossa unidade intitulada Engenharia de Proteo trata desse assunto com maiores detalhes.
ESTTICA: Interessante como esse atributo especial para a Web. Existem aplicaes que com seu aspecto especfico atraem grande nmero de usurios. Podemos citar novamente o mecanismo de busca do Google como exemplo. Atravs de sua interface minimalista essa aplicao ganhou praticamente todos os internautas. Por outro lado, a Amazon impressiona pela riqueza de detalhes que fornece aos seus usurios.
116
A engenharia de software para WebApps pode ser definida segundo Graef e Gaedke como: Aplicao de um enfoque sistemtico, disciplinado e quantificvel para o
desenvolvimento e evoluo de aplicaes Web, com alta qualidade e a um custo efetivo.
117
http://www.sembrasil.com.br/artigos/engenharia-de-software-x-engenharia-web.html http://www.ic.unicamp.br/~eliane/Cursos/MO409/Curso2004(com%20MC746)/Apres entacoes/OOHDM.ppt#256,1,Metodologia para Desenvolvimento Web http://www.inf.ufsc.br/~leandro/ensino/esp/monografiaMarcioHenriqueLocatelli.pdf http://www.cin.ufpe.br/~processos/TAES3/slides2003.1/RUPparaWeb.ppt#281,1,Slide 1 www.inf.ufsc.br/~leandro/ensino/esp/monografiaMarcioHenriqueLocatelli.pdf
Cite de memria pelo menos cinco caractersticas das aplicaes feitas para a Internet.
118
NIDADE
27
Engenharia De Software Para A Web Metodologia Objetivo: Destacar as metodologias mais adequadas para Engenharia de Software na Web. importante notar que muitos mtodos da Engenharia Web foram adaptados diretamente de seus correlatos da Engenharia de Software clssica. Outros ainda esto em seus estgios de formao e em processo de maturidade. Alguns deles vo sobreviver, outros sero descartados medida que melhores abordagens forem sugeridas (adaptado de Pressman, 2006). O processo WebE (Engenharia Web) adota a filosofia de desenvolvimento gil que enfatiza uma abordagem de engenharia simples que leva entrega incremental do sistema a ser construdo. O modelo de processo da WebE est fixado em trs pontos: 1. ENTREGA INCREMENTAL: as atividades vo ocorrer repetidamente medida que cada incremento submetido engenharia e entregue; 2. MODIFICAES CONTNUAS: as modificaes ocorrem devido aos resultados da avaliao de um incremento entregue, ou como consequncia de condies de negcios mutveis; 3. CRONOGRAMAS CURTOS: com prazos curtos exige a necessidade de criar estratgias especiais para a documentao de engenharia. No entanto, a anlise, projeto e teste crtico devem ser registrados de algum modo. Susan Weinshenk, em seu livro Psychology and the Web: Designing for People, sugere um conjunto de questes que devem ser consideradas medida que anlise e o projeto progridem. Um pequeno subconjunto aqui citado:
119
Quo importante uma pgina principal de um site Web? Ela deve conter informao til ou uma simples lista de links que levam um usurio a ter mais detalhes em nveis mais baixos?
Qual o leiaute de pgina mais efetivo (por exemplo, menu no topo, direita ou esquerda?) e ele varia dependendo de tipo da WebApp que est sendo desenvolvido?
Que opes de mdia tm maior impacto? Os grficos so mais efetivos do que o texto? O vdeo (ou udio) uma opo eficaz? Quando as vrias opes de mdia devem ser escolhidas?
Quanto de trabalho pode-se esperar que um usurio faa quando ele ou ela est procurando a informao? Quantos cliques as pessoas esto dispostas a fazer?
Quo importantes so os apoios navegacionais quando as WebApps so complexas ? Quo complexo pode ser o formulrio de entrada antes que ele se torne irritante para o usurio? Como os formulrios de entrada podem ser manipulados?
Quo importantes so os recursos de busca? Que porcentagem de usurios navega, e que porcentagem usa buscas especficas? Quo importante estruturar cada pgina de um modo que aceite um link de alguma fonte externa?
A WebApp ser projetada para que seja acessvel queles que tm deficincias fsicas ou outras ?
Veja a importncia do planejamento em tudo isso atravs das palavras de Constantine e Lockwood (User-Centered Engineering for Web Apllications, 2002):
Apesar das declaraes sem flego de que a Web representa um novo paradigma definido por novas regras, os desenvolvedores profissionais esto percebendo que as lies aprendidas nos dias do desenvolvimento de software antes da Internet ainda se aplicam. Pginas Web so interfaces com o usurio. Programao HTML programao, e aplicaes implantadas por navegador so sistemas de software que podem se beneficiar dos princpios bsicos e engenharia de software.
Como voc julga a qualidade de um site Web? Faa uma lista ordenada por ordem de importncia dos atributos de qualidade que voc acredita ser os mais importantes.
121
NIDADE
28
Engenharia De Software Para A Web Oohdm Objetivo: Definir o mtodo OOHDM e suas principais caractersticas. As WebApps esto tornando-se cada vez mais complexas devido aos vrios aspectos e tecnologias adicionais e especficas, alm da complexidade natural do negcio. No entanto, os mtodos e as tcnicas tradicionais da Engenharia de Software no so adequados para o domnio Web, que tem requisitos prprios. Segundo Rossi, Schwabe e Lyardet (1999), as principais diferenas entre WebApp e aplicaes tradicionais (cliente-servidor) referem-se a questes de navegao, de interface e de implementao. Tendo em vista que WebApp pode ser considerada um tipo de produto de software, vrios mtodos especficos para o seu desenvolvimento tm sido propostos e sistematizam as fases de anlise, de projeto e de implementao, com foco na modelagem do domnio e da organizao estrutural e navegacional. Dentre os diversos mtodos e modelos para a especificao de aplicaes hipermdia encontrados atualmente, o mtodo OOHDM tem se mostrado o mtodo mais maduro, devido a sua ampla utilizao pela comunidade hipermdia para projetos de diversas aplicaes Web em diversos pases. OBS.: Na literatura tcnica iremos encontrar o termo de desenvolvimento de uma aplicao hipermdia com o mesmo significado do desenvolvimento de software para a Web. O desenvolvimento de uma aplicao hipermdia, ou seja, desenvolvimento de software para a Internet, compreende duas etapas principais:
122
1. A especificao da aplicao atravs de um mtodo de projeto (por exemplo, o Object Oriented Hypermedia Design Method OOHDM) e; 2. A devida implementao em alguma linguagem (atravs de um ambiente de suporte).
OOHDM O Object Oriented Hipermidia Design Method (OOHDM) permite o projeto de aplicaes que seguem o paradigma de hipermdia, como as aplicaes na Web. Ele uma evoluo da experincia acumulada com o Hypermedia Design Model (HDM), trabalho realizado em 1990 por Daniel Schwabe, Franca Garzotto e Paolo Paolini, no Politecnico di Milano, que foi o primeiro modelo proposto para aplicaes hipermdia. No desenvolvimento de aplicaes hipermdia, h a necessidade de se utilizar de um modelo de base, que possa nortear as etapas de construo do projeto e o uso da tecnologia relacionada. Schwabe prope o uso do mtodo OOHDM (Object-Oriented Hypermidia Design Method), que composto por quatro atividades diferentes: 1. Modelo conceitual: modela a semntica do domnio da aplicao. 2. Projeto da Navegao: leva em considerao o perfil do usurio e a tarefa a ser executada, dando nfase nos aspectos cognitivos. 3. Projeto da interface abstrata: modela objetos perceptveis, implementa as metforas escolhidas e descreve a interface para os objetos navegacionais. 4. Implementao: A implementao de uma aplicao hipermdia complexa. Muitas questes tcnicas e no-tcnicas devem ser resolvidas. Uma vez que o ambiente de implementao tenha sido escolhido, o projeto deve ser mapeado para artefatos de implementao e todos os componentes hipermdia tm de ser instanciados.
123
Atividades
Produtos
Mecanismos
Interesses Projeto
do
Classes, subsistemas,
Modelagem Conceitual
Classificao, composio, generalizao especializao. Mapeamento entre
Modelagem semntica e domnio aplicao.
da do de
relacionamentos, perspectivas atributos. de
Ns, estruturas
Projeto da Navegao
elos, objetos conceituais de e de navegao. de
Leva
em
conta
acesso, contextos Padres de
perfil do usurio e a tarefa; nfase em
navegao, navegao para a descrio da
transformaes navegacionais.
aspetos cognitivos e arquiteturais.
estrutura geral da aplicao.
Modelagem Objetos de
de
objetos perceptveis, entre implementa de metforas e escolhidas. Descrio de
interface abstrata, Mapeamento reaes a eventos objetos

Projeto da Interface Abstrata
externos,
navegao
transformaes de objetos de interface. interface.
interface para objetos navegacionais.
Aplicao
Impl em ent ao
em Aqueles fornecidos Desempenho, pelo ambiente alvo. completitude.
execuo.
Adaptado da dissertao de Gustavo Rossi sobre OOHDM
124
Benefcios da OOHDM So utilizadas as mesmas primitivas de modelagem (objetos, classes), simplificando a transio de uma atividade para outra. Ao longo do processo utilizamos agregao, classificao e generalizao/especializao. Pelo fato de os objetos serem artefatos reativos, podem ser construdas aplicaes sofisticadas baseadas em hipermdia, definindo-se padres de comportamento e de comunicao entre objetos. H poderosos formalismos, j existentes para especificar a estrutura, o comportamento e as relaes dos objetos e podemos adapt-los ao campo da hipermdia. Aplicaes projetadas e construdas em torno de objetos tendem a ser mais robustos e fceis de modificar, tanto pelo uso de polimorfismo e herana como por composio. Fornecemos primitivas de modelagem de alto nvel na forma de padres de projeto que podem ser utilizadas sem alteraes, ou modificadas de acordo com as necessidades do projetista. Construir novas aplicaes reutilizando componentes existentes altamente vivel quando os componentes so descritos como objetos.
Veja o WIKI construdo sobre o OOHDM: http://www.tecweb.inf.puc-rio.br/oohdm/space/start http://atlas.ucpel.tche.br/~lla/resumo.htm
125
1. Visite o site http://www.porkworld.com.br/index.php?documento=109 e estude o case apresentado. O que voc acha desse tipo de aplicao? 2. Assista a entrevista feita por Marcio Gomes, no programa Espao Aberto da Globonews, atrvs do site: http://www.inf.puc-rio.br/~schwabe/DS_Espaco_Aberto_5-5-03.avi
126
NIDADE
29
Planejamento Da Webapp Objetivo: apresentar as tcnicas de planejamento de projetos aplicados a Web. A gesto de projetos WebE pequenos e de tamanho moderado (menos de 5 meses), requer uma abordagem gil que no enfatize a gesto do projeto, mas que no elimine a necessidade de planejar. Princpios bsicos de gesto de projeto ainda se aplicam, mas a abordagem global mais simples e menos formal. Seguem os passos recomendados para esses tipos de projetos: 1. Entenda o escopo, as dimenses das modificaes e as restries de projeto: no se pode comear um projeto sem antes entender at onde ele ir, e o que ele aborda. Coleta de requisitos e comunicao com os clientes e usurios so antecedentes essenciais para o planejamento efetivo da WebApp. 2. Defina uma estratgia de projeto incremental: Como falamos anteriormente as aplicaes Web evoluem com o tempo. Se essa evoluo no for bem planejada em longo prazo, as chances de sucesso sero pequenas. 3. Realize anlise de risco: os principais itens de preocupao as equipes de engenharia da Web so o risco de cronograma e risco de tecnologia. Preocupaes quanto ao cumprimento dos prazos, e o domnio das tecnologias que sero adotadas pela equipe devem ser devidamente ponderadas. 4. Desenvolva uma rpida estimativa: o enfoque da estimativa do projeto deve ser basicamente em tpicos macroscpicos. No deve existir a preocupao maior em levantar tpicos microscpicos, pois demandaria mais controles burocrticos.
127
5. Descreva o processo: selecione um conjunto de tarefas significativas que seja adequado para as caractersticas do problema, do produto, do projeto e do pessoal da equipe de engenharia. 6. Estabelea um cronograma: deve-se adotar a estratgia de elaborar o cronograma com dois critrios bem distintos. Determinar as tarefas a serem realizadas em curto prazo com granularidade fina no cronograma. E com granularidade grossa para os incrementos adicionais que tiverem que ser entregues posteriormente. 7. Defina mecanismos para acompanhar o projeto: no desenvolvimento gil, a entrega de um incremento operacional de software a medida principal de progresso. Uma abordagem a ser adotada determinar quantos casos de uso foram implementados e quantos dos casos de uso ainda restam ser implementados. Isso fornecer uma indicao grosseira do relativo grau de completeza do incremento de projeto. 8. Estabelea uma abordagem de modificao: como o prazo de desenvolvimento para um incremento pequeno, frequentemente possvel adiar a introduo de uma modificao at o prximo incremento, reduzindo, assim, os efeitos de atraso associados a modificaes que precisam ainda se implementadas para ontem.
http://www.avellareduarte.com.br/projeto/planejamento/planejamento2/planejament o2_gestaoCriacao.htm
128
Como voc relacionaria o contedo apresentado nesta unidade com o PMBOK ?
129
NIDADE
30
Ferramentas De Software Para Gesto De Projetos Web Objetivo: Apresentar ferramentas de sofware para apoio a gesto de projetos na Web. Com o objetivo de apoiar a equipe de engenharia da Web no planejamento, gesto, controle e rastreamento de projetos existem vrias ferramentas na prpria Internet que facilitam esse trabalho. Ferramentas de gesto de projeto possibilitam a uma equipe de WebE estabelecer um conjunto de tarefas de trabalho, atribuir esforo e responsabilidade especfica para cada tarefa, estabelecer as dependncias de tarefas, definir um cronograma, e acompanhar e controlar as atividades no projeto. Ferramentas mais representativas Business Engine, desenvolvida por Business Engine (www.businessengine.com), um conjunto de ferramentas baseadas na Web que fornece plenas facilidades de gesto de projeto para projetos de WebE e de software convencional.
130
iTeamwork:, desenvolvida por iTeamwork.com (www.iteamwork.com), uma aplicao livre, on-line, baseada na Web, de gesto de equipe de projeto que voc usa com o seu prprio navegador Web.
OurProject: desenvolvida por Our Project (www.ourproject.com) , um conjunto de ferramentas de gesto de projetos que aplicado a projetos da WebE e de software convencional.
Proj-Net:, desenvolvida por Rational Concepts, Inc. (www.rationalconcepts.com), implementa um escritrio virtual de projeto (virtual Project Office, VPO) para colaborao e comunicao.
131
StartWright
(www.startwright.com/project1.htm)
desenvolveu
um
dos
recursos
mais
abrangentes da Web tanto para WebE, quanto para software convencional de ferramentas e informao de gesto de projetos.
http://www.businessengine.com http://www.iteamwork.com http://www.ourproject.com http://www.rationalconcepts.com http://www.startwright.com/project1.htm
132
Nesta unidade exploramos o planejamento para aplicaes Web, um dos itens desta unidade foi intitulado Ferramentas mais representativas. Visite os sites recomendados e explore a ferramentas sugeridas realizando um pequeno resumo do potencial de cada um desses softwares.
OBS.: pelo fato da Internet ser extremamente dinmica, pode ocorrer que alguns sites recomendados estejam fora do ar, ou substitudos ao longo deste trabalho.
Antes de dar incio sua Prova Online fundamental que voc acesse sua SALA DE AULA e faa a Atividade 3 no link ATIVIDADES.
133
Atividade Dissertativa Desenvolva uma pesquisa gerando um texto, de 2 a 3 folhas adicionando imagens, de uma das unidades da nossa apostila, de sua livre escolha, permitindo a expanso da temtica selecionada. Ateno: Qualquer bloco de texto igual ou existente na internet ser devolvido para que o aluno o realize novamente.
134
LOSSRIO
Caso haja dvidas sobre algum termo ou sigla utilizada, consulte o link Glossrio em sua sala de aula, no site da ESAB.
135
EFERNCIAS
PRESSMAN, Roger. Engenharia de Software. So Paulo: McGraw-Hill Brasil, 2006 SOMMERVILLE, Ian. Engenharia de Software. So Paulo: Pearson Addison Wesley, 2007 REZENDE, Denis Alcides. Engenharia de Software e Sistemas de Informao. Rio de
Janeiro: Brasport, 2005.
136

Tópicos Avançados de Engenharia de Software

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Tópicos Avançados de Engenharia de Software

Hochgeladen von

Copyright:

Verfügbare Formate

MDULO DE:

TPICOS AVANADOS de ENGENHARIA de SOFTWARE

Ms. Carlos Valente

Copyright 2008, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Primeira edio: 2008

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Gerncia De Engenharia De Software Gerencia projetos de desenvolvimento de software.

http://www.swebok.org/ http://pt.wikipedia.org/wiki/Software_Engineering_Body_of_Knowledge http://www.cic.unb.br/~jhcf/MyBooks/iess/Intro/10AreasDaEngenhariaDeSoftware.pdf http://www.cin.ufpe.br/~dar/SWEBOK%20cinco%20areas%20da%20eng%20software%20-%20dar.pdf

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

http://pt.wikipedia.org/wiki/Arquitetura_de_software Um site dedicado a discusso das arquiteturas de sistema: http://www.softwarearchitectures.com http://www.sei.cmu.edu/architecture/published_definitions.html

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

http://www.cl.cam.ac.uk/%7Erja14/book.html http://download.cissp.com.br/Ed.001_20.09.06.pdf http://camargoneves.com/Apresentacoes/unicap_proespe.pdf

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Pesquise o excelente filme Prenda-me se for capaz.

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

significativos p/ os usurios no modificar

Copyright 2007, ESAB Escola Superior Aberta do Brasil

http://pt.wikipedia.org/wiki/Interface_do_utilizador http://www.pucrs.campus2.br/~jiani/trabalhos/levacov.htm http://www.dcce.ibilce.unesp.br/~ines/cursos/eng_soft/aula11.PDF http://www.dimap.ufrn.br/~jair/piu/JAI_Apostila.pdf

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

http://www.dstan.mod.uk/ http://www.poli.usp.br/pro/procsoft/tpcsepusp03.pdf http://www.lbd.dcc.ufmg.br:8080/colecoes/sbes/2001/002.pdf

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil