Escolar Documentos
Profissional Documentos
Cultura Documentos
Volume 2
Recife, 2010
Universidade Federal Rural de Pernambuco Reitor: Prof. Valmar Corra de Andrade Vice-Reitor: Prof. Reginaldo Barros Pr-Reitor de Administrao: Prof. Francisco Fernando Ramos Carvalho Pr-Reitor de Extenso: Prof. Paulo Donizeti Siepierski Pr-Reitor de Pesquisa e Ps-Graduao: Prof. Fernando Jos Freire Pr-Reitor de Planejamento: Prof. Rinaldo Luiz Caraciolo Ferreira Pr-Reitora de Ensino de Graduao: Prof. Maria Jos de Sena Coordenao Geral de Ensino a Distncia: Prof Marizete Silva Santos
Produo Grfica e Editorial Capa e Editorao: Rafael Lira, Italo Amorim e Arlinda Torres Reviso Ortogrfica: Marcelo Melo Ilustraes: Allyson Vila Nova, No Aprgio e Igor Leite Coordenao de Produo: Marizete Silva Santos
Sumrio
Apresentao................................................................................................................. 4 Conhecendo o Volume 2 ................................................................................................ 5 Captulo 1 Engenharia de Requisitos............................................................................ 6 1.1 Requisitos de Software ..............................................................................................6 1.2 Engenharia de Requisitos (ER) e Engenharia de Software (ES) ................................10 1.3 Ponto de partida para um processo de ER ..............................................................12 1.4 Processo Genrico da ER .........................................................................................13 Captulo 2 Projeto de Software .................................................................................. 28 2.1 Projeto e Engenharia de Software ...........................................................................28 2.2 Princpios e tcnicas do projeto de software ...........................................................31 2.4 Modelos de projeto .................................................................................................36 Captulo 3 Verificao, validao e teste do software (VVT) ....................................... 44 3.1 Introduo s atividades de VVT .............................................................................45 3.2 Algumas tcnicas de verificao ..............................................................................47 3.3 Testes de software ...................................................................................................49 3.4 Classificao dos testes............................................................................................52 3.5 Processo de testes ...................................................................................................54 Consideraes Finais .................................................................................................... 63 Conhea a Autora ........................................................................................................ 64
Apresentao
Caro(a) Cursista, Seja bem-vindo(a) segunda unidade do curso Fundamentos da Engenharia de Software. Na unidade anterior, vimos brevemente as caractersticas do software, introduzimos o que Engenharia de Software e tambm mostramos o SWEBOK como uma iniciativa para sedimentar a disciplina de ES na indstria e melhorar a qualidade da profisso. Como continuao, esta segunda unidade abordar as reas de conhecimento base da Engenharia de Software segundo o SWEBOK e que tambm so comuns a maior parte dos processos de desenvolvimento. Iremos conhecer um pouco de Engenharia de Requisitos, da Anlise e Projeto de Software e da Verificao, Validao e Testes. Para quem deseja ser um profissional desenvolvedor, os assuntos explicados nesta unidade sero essenciais para sua formao, ento os estude com dedicao.
A vitalidade no se revela apenas na capacidade de persistir, mas tambm na de comear tudo de novo. (Scott Fitzgerald)
Conhecendo o Volume 2
Neste segundo volume, voc ir encontrar o Mdulo 2 da disciplina Fundamentos da Engenharia de Software. Para facilitar seus estudos, veja a organizao desta segunda unidade.
Objetivo do Mdulo 2:
Apresentar algumas das reas bsicas de conhecimento da Engenharia de Software, como: Engenharia de Requisitos, Anlise e Projeto de Software, e Verificao, validao e testes de software.
As descries das funes e restries so os requisitos do sistema; Um requisito uma propriedade que o software deve exibir para resolver algum problema no mundo real; Uma condio ou uma capacidade que deve ser alcanada ou estar presente em um sistema para satisfazer um contrato, padro, especificao ou outro documento formalmente imposto.
Percebe-se que as citaes encontradas definem o mesmo conceito sob diferentes perspectivas. Podemos entender requisitos como sendo o conjunto de necessidades explicitadas pelo cliente/usurio que devero ser atendidas para solucionar um determinado problema do negcio no qual o cliente/usurio faz parte. importante estar atento para esta definio: embora o requisito seja definido pelo cliente, nem sempre o que o cliente quer o que o negcio precisa. Cabe equipe que estar levantando os requisitos identificar a real necessidade do negcio. Um conjunto de requisitos pode ser definido como uma condio ou capacidade necessrias que o software deve possuir (1) para que o usurio possa resolver um problema ou atingir um objetivo ou (2) para atender as necessidades ou restries da organizao ou dos outros componentes do sistema. Os requisitos so importantes para: Estabelecer uma base de concordncia entre o cliente e o fornecedor sobre o que o software far; Fornecer uma referncia para a validao do produto final; Reduzir o custo de desenvolvimento (requisitos mal definidos causam retrabalho).
De acordo com Presman (2006), existem trs tipos de requisitos: de usurio, de sistemas, e de software. Os requisitos de usurio representam declaraes em linguagem natural e tambm em diagramas sobre as funes que o sistema deve fornecer e as restries sob as quais deve operar. Os requisitos do sistema constituem um documento estruturado que estabelece detalhadamente as funes e as restries de sistema. Escrito como um contrato entre o cliente e o desenvolvedor. E por ltimo se tem os requisitos do software que compreendem uma descrio detalhada do software que serve como base para projeto e a implementao. Cada um desses tipos de requisitos atende a um conjunto especfico de pblico (Figura 1.1).
No decorrer deste captulo, quando falarmos de requisitos, estaremos nos referindo aos requisitos do software. Neste contexto, os requisitos expressam as caractersticas e restries do produto de software do ponto de vista de satisfao das necessidades do usurio/cliente e, em geral, independem da tecnologia empregada na construo da soluo sendo a parte mais crtica e propensa a erros no desenvolvimento de software. Tradicionalmente, os requisitos do software so separados em requisitos funcionais e no-funcionais. Outro tipo de requisito o de domnio. Estes se originam do domnio da aplicao do sistema e que refletem caractersticas desse domnio, mas eles sempre se encaixaro em uma dessas duas categorias: requisitos funcionais e no funcionais.
A especificao de um requisito funcional deve determinar o que se espera que o software faa, sem a preocupao de como ele faz. importante diferenciar a atividade de especificar requisitos da atividade de especificao que ocorre durante o projeto do software. No projeto do software deve-se tomar a deciso de quais as funes o sistema efetivamente ter para satisfazer quilo que os usurios querem.
Requisitos no funcionais dizem respeito ao sistema como um todo. Alguns podem restringir o processo que utilizado para desenvolver o sistema (ditar um sistema CASE especfico, linguagem de programao ou mtodo de desenvolvimento). Podem ser mais crticos que requisitos funcionais. A falha em atender um requisito no funcional de sistema pode inutilizar o sistema. Os requisitos no funcionais subdividem-se em trs categorias: de produtos, organizacionais e externos. Os de produto especificam o comportamento do software como, inclusive, j citamos alguns. Por exemplo: velocidade de execuo, confiabilidade, portabilidade, facilidade de uso, etc. Os organizacionais so consequncia de polticas de procedimentos nas organizaes do cliente e do desenvolvedor, por exemplo, padres de processos que devem ser utilizados, requisitos de implementao. E os externos so procedentes de fatores externos ao sistema e a seu processo de desenvolvimento, por exemplo, requisitos de interoperabilidade, requisitos legais e os requisitos ticos. Devido sua prpria definio, requisitos no-funcionais tambm so esperados ser mensurveis, caso contrrio seria impossvel validar a corretude e completude do requisito. Assim, deve-se associar forma de medida/referncia a cada requisito nofuncional elicitado. Alguns exemplos dessas medidas so ilustradas no quadro a seguir.]
Quadro 1.1 Medidas para requisitos no-funcionais. Propriedade Velocidade Tamanho Facilidade de uso Medida Transaes processadas/seg; Tempo de resposta do usurio/evento K bytes; No de chips de RAM Tempo de treinamento; No de quadros de ajuda Tempo mdio de falhas; Confiabilidade Probabilidade de indisponibilidade Taxa de ocorrncia de falhas Tempo de reincio aps falha; Robustez Percentual de eventos causando falhas Probabilidade de corrupo de dados aps falha Portabilidade Percentual de declaraes dependentes do destino; No de sistemas destino
A necessidade de se estabelecer os requisitos de maneira de forma precisa crtica na medida em que o tamanho e a complexidade do software aumenta. Os requisitos exercem influncia uns sobre os outros. Por exemplo, o requisito do software de ter grande portabilidade (por exemplo, ser implementado em Java) pode implicar em que o requisito desempenho no seja satisfeito (programas em Java so, em geral, mais lentos). Uma boa especificao de requisitos deve ser: Clara e no-ambgua
Para Refletir...
Construir um sistema de software com base em requisitos inconsistentes e mal definidos como construir uma casa sem alicerce na areia...
No contexto da Engenharia de Software, a rea de engenharia de requisitos est concentrada com a elicitao, anlise, especificao, validao e gerncia de requisitos de software (Figura 1.2). J consolidado para a indstria de software que quando a elicitao, anlise, especificao e validao so feitas incorretamente ou so incompletas podem fazer com que o produto final de software falhe em suas funes, e isso algo que necessita ser evitado sempre.
10
Neste ponto podemos citar alguns dos principais objetivos da ER, so eles: Estabelecer uma viso comum entre o cliente e a equipe de projeto em relao aos requisitos que sero atendidos pelo projeto de software; Registrar e acompanhar requisitos ao longo de todo o processo de desenvolvimento; Documentar e controlar os requisitos alocados para estabelecer uma linha de referncia de verses para uso gerencial e da engenharia de software; Manter planos, artefatos e atividades de software consistentes com os requisitos alocados.
Para Refletir...
Por que ser to difcil obter um entendimento claro do que o cliente deseja? Discuta com seus colegas de curso.
Para apoiar o alcance destes objetivos, importante que se tenha um processo de engenharia de requisitos bem definido. Um processo de engenharia de requisitos um conjunto estruturado de atividades a serem seguidas para criar, validar e manter um documento de requisitos. Poucas organizaes tm um processo de ER explicitamente definido e padronizado. Entretanto, sugere-se que cada organizao deva desenvolver um processo adequado sua realidade. Contudo, as entradas e sadas desse processo normalmente so as apresentadas na Figura 1.3.
11
12
cada verso? Como saber que requisitos mudaram de uma verso para outra? O processo de ER no especifica essa atividade, mas necessrio identificar processos de suporte para realizar tal atividade, seno a gerncia dos requisitos ficar catica e dificultar a manuteno certa do software. Definio dos processos de melhorias do processo de ER: outro ponto importante a se pensar definir como o processo de ER ser melhorado com o uso e experimentao.
Esses so os pontos bsicos para iniciar um processo de ER em sua empresa, por exemplo, ou mesmo para o desenvolvimento de um software especfico. Assim, para definir um processo para ER, voc precisar primeiramente definir: o modelo de ciclo de vida que o processo executar, os atores do processo, as atividades e os mecanismos de gerenciamento, suporte e melhoramento.
13
Os requisitos podem ser originados de vrias fontes. Por exemplo, os requisitos podem ser descobertos do conhecimento do domnio no qual o software atuar, podem ser originados dos stakeholders, do ambiente operacional e organizacional no qual o software
14
trabalhar, dentre outras fontes. O importante que o responsvel por essa elicitao tente cobrir o maior nmero de fontes possvel para evitar especificaes errneas, ambguas e/ ou incompletas. A atividade de levantamento de requisitos no trivial, apesar de aparentar o contrrio. Existe um conjunto grande e variado de fatores que a tornam complexa, por exemplo: Falta de conhecimento das suas reais necessidades Cliente/Usurio com vaga noo do que precisa e do que um produto de software pode oferecer. Falta de conhecimento do desenvolvedor do domnio do problema Desenvolvedor sem conhecimento adequado do domnio, o que leva a decises erradas. Domnio do processo de levantamento de requisitos pelos desenvolvedores Desenvolvedor no ouve o que os clientes/usurios tm a dizer e fora suas prprias vises e interpretaes. Comunicao inadequada entre os desenvolvedores e usurios/clientes: usurios/ clientes incapazes de expressar suas necessidades apropriadamente; significados diferentes a termos comuns. Dificuldade do usurio tomar decises Falta de entendimento sobre as consequncias das decises ou as alternativas possveis. Problemas de comportamento: o levantamento de requisitos um processo social; conflitos e ambiguidades nos papis que os usurios e desenvolvedores desempenham. Questes tcnicas: complexidade crescente dos sistemas atuais.
Para auxiliar a superar estes problemas, os responsveis pela elicitao devem abordar os requisitos de maneira organizada. Alguns passos so sugeridos para elicitao de requisitos: Avaliar a viabilidade tcnica e de negcio para o sistema proposto; Identificar as pessoas que vo auxiliar a especificar os requisitos e compreender seus preconceitos organizacionais; Definir o ambiente tcnico no qual o sistema ser instalado; Identificar regras de domnio que limitam a funcionalidade ou desempenho do sistema ou produto que ser construdo; Definir um ou mais mtodos de elicitao de requisitos; Solicitar participao de vrias pessoas para que os requisitos sejam definidos a partir de diversos pontos de vista; Identificar claramente a justificativa de existncia para cada requisito registrado; Identificar requisitos ambguos que sero candidatos a prototipao.
Os produtos de trabalho a criar como consequncia das atividades de elicitao de requisitos iro depender do tamanho do sistema ou produto que ser construdo. Para a maioria dos sistemas, estes produtos de trabalho incluem: As necessidades e viabilidade estruturadas
15
O limite de escopo do sistema ou produtos; Uma lista de clientes, usurios e outros stakeholders que participaram da atividade de elicitao de requisitos; Uma descrio do ambiente tcnico do sistema; Uma lista de requisitos e as regras de domnio aplicveis a cada um. Um conjunto de cenrios de uso capazes de prover uma ideia do uso do sistema ou produto sob diferentes condies de operao; Qualquer prottipo que eventualmente tenha sido desenvolvido para melhor definir os requisitos. Cada um destes produtos deve ser revisado por todas as pessoas que tenham participado da elicitao de requisitos.
Para facilitar e buscar um melhor resultado no processo de elicitao de requisitos, h algumas tcnicas propostas. No podemos dizer aqui qual a melhor ou pior, tudo vai depender do contexto em que o software atuar e ser desenvolvido. O importante voc ter conhecimento delas e quando adequado usar uma a outra, ou at mais de uma dependendo do momento do ciclo de desenvolvimento do software.
Para Refletir...
A parte mais rdua na construo de um software consiste exatamente em identificar o que construir. Nenhuma outra parte do trabalho compromete tanto o resultado do trabalho se elaborado de forma incorreta. Nenhuma outra parte oferece tanta dificuldade para efetuar correes posteriores. Fred Brook
Essa tcnica est condicionada a alguns fatores: Influncia do entrevistador nas respostas do cliente/usurio: convm que o entrevistador d margem ao entrevistado para expor as suas ideias sem as enviesar logo partida. Relao pessoal entre os intervenientes na entrevista.
16
Predisposio do entrevistado: caso, por exemplo, o papel do entrevistado venha a ser afetado pela introduo de um sistema na organizao, este pode propositadamente dificultar o acesso informao. Capacidade de seguir um plano para a entrevista: na ausncia destes planos natural que haja tendncia para que os intervenientes se dispersem um pouco, levando a que a entrevista demore mais tempo do que seria suposto. Caso a entrevista se torne demasiado longa, as pessoas podem cair na tentao de querer despachar sendo os ltimos pontos da entrevista abordados de forma superficial (ou podem nem chegar a ser abordados).
Alguns exemplos de perguntas a responder
1. Quemm so o cliente e o usurio? 2. Possuem necessidade diferentes? 3. Qual o problema? 4. Como resolvido atualmente? 5. Qual a razo para resolv-lo? 6. Qual o valor de uma soluo bem-sucedida? 7. Onde mais uma soluo pode ser encontrada? Figura 1.5 Perguntas a responder em uma entrevista.
b) Questionrio: O emprego do Questionrio se justifica quando se deseja coletar dados de pessoas fisicamente distantes ou que constituem um grupo numeroso de pessoas a serem inquiridas. Para facilitar a sua elaborao deve-se, inicialmente, elaborar um esquema que possa congregar ttulos de assunto de mesma natureza. c) Tempestade de ideias (do ingls, brainstorming): Trata-se de uma tcnica realizada em um ambiente mais informal, propcio criao de ideias para soluo de um problema, toda a ideia deve ser levada em considerao, proibido a critica a qualquer que seja a sugesto dada, encorajada a criao de ideias bizarras. Ocorrem em um grupo de 6 a 12 pessoas, com a presena de um moderador, que quem gerencia toda a discusso. Uma das desvantagens dessa tcnica que pode demorar a se conseguir um ideia, ou um conjunto delas, que resolva o problema. Essa uma tcnica muito utilizada no projeto de jogos digitais. d) Pesquisas: a pesquisa institucional e/ou reviso bibliogrfica deve ser a primeira tcnica empregada em um levantamento, pois oferece suporte s demais, possibilitando um entendimento mais direcionado ao assunto a ser tratado. A reviso bibliogrfica consiste em pesquisar a literatura pertinente (livros, revistas especializadas, legislao, artigos, etc) e a pesquisa Institucional consiste basicamente em identificar, na empresa, trabalhos que j foram desenvolvidos sobre os assuntos (estatuto social, regimentos, normas, regulamentos,manuais, instrues normativas, relatrios, etc). e) JAD(Joint Application Design): Trata-se do agrupamento de ferramentas,
17
cooperao e participao de todas as partes envolvidas, desde os usurios at os profissionais de TI. Segundo Damian (1997), JAD consiste de 5 fases: definio do projeto, pesquisa, preparao para a sesso JAD, a sesso JAD, o documento final. Um das dificuldades dessa tcnica justamente a comunicao efetiva entre pessoas de reas, muitas vezes, distintas. f) Prototipao: essa tcnica consiste em construir, a partir dos requisitos iniciais, um prottipo do produto para ser testado pelo usurio/cliente. O ponto forte desta atividade apresentar muitas alternativas para o usurio antes de se gastar muito esforo para qualquer prottipo em particular. O uso de prototipagem feito em diversas fases do processo de engenharia de requisitos (por exemplo na identificao, anlise e validao). O uso de prottipos deve ser considerado apenas mediante uma anlise custo-benefcio, j que os custos de desenvolvimento de um prottipo podem facilmente crescer, sendo particularmente teis em situaes em que a interface com os utilizadores , para eles, um aspecto crtico. g) workshop de requisitos: consiste numa tcnica usada atravs de uma reunio estruturada, da qual devem fazer parte um grupo de analistas e um grupo representando o cliente, para ento obter um conjunto de requisitos bem definidos. Ao contrrio das reunies, promove-se a interao entre todos os elementos presentes no workshop fomentando momentos de descontraco como forma de dinamizar o trabalho em equipe, existindo um facilitador neutro cujo papel conduzir o workshop e promover a discusso entre os vrios intervenientes (ainda que no tenha realmente poder de deciso). As tomadas de deciso devem seguir processos bem definidos e devem resultar de um processo de negociao, mediado pelo facilitador. Uma tcnica que tambm til em workshops o uso de brainstorming (tempestade de ideias) como forma de gerar um elevado nmero de ideias numa pequena quantidade de tempo. Como resultado dos workshops deve ser produzida documentao que reflita os requisitos e decises tomadas sobre o sistema a implementar. h) Cenrios: uma forma de levar as pessoas a imaginarem o comportamento de um sistema o uso de cenrios. Atravs de exemplos prticos descritivos do comportamento de um sistema, os seus utilizadores podem comentar acerca do seu comportamento e da interao que esperam ter com ele. Trata-se de uma abordagem informal, prtica e aplicvel a qualquer tipo de sistema. Um exemplo de cenrio de uso tpico para um sistema da biblioteca seria:
Um aluno chega na biblioteca para procurar livros-texto dos cursos que est frequentando. Ele entra no sistema e seleciona os cursos, e obtm uma lista de todos os livros-texto e sua localizao na biblioteca. Seleciona a opo de bibliografia complementar e uma nova lista de livros e peridicos lhe apresentada. Ele ento manda imprimir todas as referncias encontradas. O tipo mais comum de cenrio o caso de uso. Os casos de uso constituem uma tcnica baseada em cenrios UML que identificam os agentes em uma interao, e
18
que descrevem a interao em si. Um conjunto de casos de uso deve descrever todas as possveis interaes com o sistema. De um modo geral, os cenrios devem incluir os seguintes elementos: Estado do sistema no incio do cenrio. Sequncia de eventos esperada (na ausncia de erros) no cenrio. Listagem de erros que podem ocorrer no decorrer dos eventos do cenrio e de como estes erros sero tratados. Outras atividades que podem ser executadas ao mesmo tempo que as deste cenrio. Estado do sistema depois de o cenrio terminar.
O objetivo da anlise e negociao dos requisitos estabelecer um acordo do conjunto de requisitos que so completos e consistentes. Estes requisitos no devem ser ambguos de forma que eles podem ser usados como uma base para o desenvolvimento do sistema. Durante o processo de anlise, requisitos perdidos, requisitos conflitantes, requisitos ambguos, requisitos duplicados e requisitos irreais so normalmente descobertos. Outra importante atividade realizada nessa fase a definio de prioridades dos requisitos. Este procedimento ajuda os stakeholders a definir as bases do sistema e a decidir sobre a arquitetura e a resolver os conflitos que surjam. As atividades iniciais de anlise dos requisitos levam identificao de classes que representem adequadamente os conceitos expressos nos requisitos, e descoberta dos respectivos atributos e relacionamentos. Esta parte da anlise fornece o modelo lgico de dados (equivalente a um modelo de entidade e relacionamentos), que pode corresponder ao modelo conceitual de um banco de dados usado pelo produto.
19
3. As propriedades gerais do sistema; 4. As definies de outros sistemas com o qual o sistema deve se integrar; 5. As informaes sobre o domnio da aplicao do sistema; 6. As descries sobre o hardware no qual o sistema ir executar. 7. Registrar a estratgia sobre o ciclo de vida do sistema. Esse documento tambm deve ser fcil de ser modificado e servir como ferramenta de referncia para a manuteno. Alm disso, necessrio um captulo introdutrio que contm um resumo do sistema, as necessidades de negcio suportadas pelo sistema e um glossrio que explica a terminologia usada. importante lembrar que este documento no deve especificar detalhes de implementao ou algo parecido, ele deve especificar o que o sistema deve fazer e no como. Existe uma especificao que a usada como declarao oficial dos requisitos do sistema. Este documento, normalmente chamado de Documento de Especificao de Requisitos (Software Requirements Specification ou SRS) inclui uma combinao dos requisitos do usurio e do sistema e tem diferentes utilidades para diferentes pessoas (SOMMERVILLE e KOTONOYA, 1997): Clientes: confirmar a completude dos requisitos e propor alteraes. Gestores: oramentar o sistema e planejar o processo de desenvolvimento. Engenheiros: compreender o sistema a desenvolver. Engenheiros (testes): desenvolver testes para validar o cumprimento dos requisitos. Engenheiros (manuteno): compreender o sistema e a ligao entre as suas partes.
Existem diversos padres para este documento, embora no se possa apontar nenhum como o ideal. Uma estrutura proposta pelo IEEE que talvez a mais usada o IEEE/ANSI 830-1993 (THAYER e DORFMAN, 1993), contudo podemos citar o modelo de Volere (2006) e Sommerville (2007). Um pequeno esboo desses modelos ilustrado na Figura 1.6.
20
21
4. Anlise automatizada da consistncia: para verificar a consistncia dos requisitos expressos em uma notao estruturada. A ferramenta CASE deve construir uma base de dados para verificao de todos os requisitos na base de dados e, ento, produzir um relatrio das inconsistncias que foram descobertas.
E no esquea, na dvida, sinta-se vontade em perguntar! Interaja com seus colegas nos fruns e chats, participe! Estamos aqui para auxiliar uns aos outros na construo do saber. Seguem alguns exemplos de atividades respondidas e/ou comentadas que sero encontradas neste captulo. No forneceremos exemplos de atividades de interao, elas so atividades simples e caracterizadas pelas discusses abertas nos fruns.
Atividades Prticas
22
de IRPF via internet. Resposta: Como requisitos funcionais, podemos citar: O sistema deve ser capaz de recuperar os dados de usurios previamente cadastrados na receita. O sistema deve ser capaz de validar o IRPF analisando se h algum erro de preenchimento antes de salvar o imposto. O sistema deve ser capaz de imprimir uma cpia do IRPF em arquivo pdf.
Como requisitos no funcionais, podemos citar: Os dados do IRPF trafegados pela internet devem ser criptografados. Para utilizar o sistema pela rede o usurio deve ter sua mquina identificada na receita federal.
2. Identifique alguns dos stakeholders envolvidos com a produo de um sistema automtico de sinalizao ferroviria. Resposta: Podemos citar como alguns dos stakeholders do software: os operadores do sistema, os condutores dos comboios, os gestores, os passageiros, os engenheiros de instalao e manuteno, as autoridades de certificao e segurana.
23
b) O sistema deve fornecer um servio confivel a todas as classes de utilizador; c) O sistema deve permitir uma resposta rpida a todos os pedidos de informao. 7. Recorrendo a exemplos, explique porque que o conhecimento do domnio importante para o processo de elicitao de requisitos. 8. Que tcnica de elicitao de requisitos voc usaria nos seguintes sistemas: a) Um jogo do estilo pacman; b) Um sistema de catalogao bibliotecria; c) Um sistema de rede social como o Twitter ou o Orkut. 9. Escreva cenrios plausveis para as seguintes atividades a) Matriculando-se num curso universitrio de educao a distancia, como este que voc est fazendo; b) Transferindo dinheiro de uma conta para outra. 10. Diga quem so os atores do processo de ER para as aes e responsabilidades especificadas na tabela. Considere para responder os atores: cliente, gestores, engenheiros. a. Utilizam o documento de requisitos para planejar, estimar, levantar riscos. b. Utilizam os requisitos para compreender que sistema deve ser desenvolvido. c. Especificam os requisitos e os leem para verificar se eles atendem a suas necessidades. Especificam as mudanas nos requisitos. d. Utilizam o documento de requisitos para ajudar a compreender o sistema e as relaes entre suas partes. 11. Fornea exemplos dos tipos de questes que devem ser preparados com antecedncia para uma entrevista visando extrao de requisitos. 12. A locadora registra os seguintes dados dos clientes: nome, endereo, cidade, telefone, RG, data de inscrio e atribui um cdigo a cada cliente. Os clientes fazem uma locao a qual atribuda um nmero sequencial e deve registrar o scio que locou e a data da locao. Cada cliente em cada locao pode alugar diversas fitas. As fitas possuem cdigo e ttulo, pertencem a uma determinada categoria de filmes (romance, comdia,aventura, etc.) e esto classificadas como lanamento, especial, ouro ou prata. Descreva: a) Funes e restries do sistema; b) Ambiguidades do sistema; c) Aplique um conjunto de perguntas que vise esclarecer o maior nmero de dvidas, omisses e ambiguidades. 13. Explique porque til envolver pessoas com formaes diferentes num processo de reviso de requisitos. 14. D exemplos de tipos de problemas que podem ser descobertos numa verificao de um documento de requisitos. 15. Explique porque que as matrizes de rastreabilidade podem se tornar difceis de
24
Ateno
As respostas das questes dessa seo podem ser facilmente encontradas relendo os textos do capitulo. Aproveite essa oportunidade para fixar melhor os pontos principais do contedo abordado no capitulo.
25
b) O que voc acha que acontece quando a validao de requisitos descobre um erro? Quem est envolvido na correo do erro? c) Discuta com seus colegas a figura a seguir. Que problema ela aborda? Que atividades da ER poderiam ser executadas para amenizar os problemas?
Conhea Mais
Existem diversos stios, artigos e livros que falam sobre a Engenharia de Requisitos, infelizmente muitos esto em ingls, mas para aqueles que querem se aprofundar sobre o assunto, a leitura muito recomendada. Aqui estamos sugerindo algumas leituras adicionais para complementar o seu conhecimento sobre o assunto. O seguinte artigo uma compilao de trechos do livro Anlise de Sistemas Orientada ao Sucesso: Por que os projetos atrasam? liberada para o JavaFree pelo autor Daniel Batista Fernandes e pela editora Cincia Moderna. O livro foi lanado em 2005 e j est entre as principais referncias em anlise de sistemas da lngua portuguesa.Disponvel em: <http://javafree.uol.com.br/artigo/871451/Especificacao-deRequisitos-uma-abordagem-orientada-ao-sucesso.html> Leia no sitio Wikipdia o que Engenharia de requisitos. Disponivel em: <http://
pt.wikipedia.org/wiki/Engenharia_de_requisitos>
Caso voc deseje conhecer um pouco mais sobre especificao de requisitos usando casos de uso, tcnica muito utilizada nos dias de hoje, leia o artigo Especificando requisitos usando casos de uso da revista DevMedia. O artigo disponibilizado eletronicamente. Disponivel em: <http://www.devmedia.com.br/articles/viewcomp.
asp?comp=10245>.
26
Voc Sabia?
Veja algumas curiosidades atualizadas sobre requisitos de software. Voc sabia que... Pesquisas realizadas pela Standish Group sobre os fatores crticos determinantes de fracasso dos projetos de software apontaram que trs dos principais fatores esto relacionados s atividades de requisitos: (1) Requisitos Incompletos; (2) Falta de Envolvimento do Usurio; (6) Mudana de Requisitos e Especificaes.. Fonte: Standish Group. Disponivel em: <www.standishgroup.com/chaos.html>
Dica de Cinema
Para complementar o conhecimento que foi exposto neste captulo, voc pode acessar alguns vdeos-aula curtinhos disponibilizados livremente na Internet (YouTube). O contedo claro, objetivo e correto. Vale a pena ser visto! Vdeo-aula sobre o processo de engenharia de requisitos. Disponvel em: <http://www. youtube.com/watch?v=o5LeCACRb48> Entrevista com um analista de sistema que descreve os problemas mais comuns identificados no desenvolvimento de software. Disponvel em: <http://www.youtube.com/watch?v=KP4Q3r_FaI&NR=1>
Vamos Revisar?
Resumo
Os requisitos estabelecem o que o sistema deve fazer e definem restries sobre sua operao e implementao. Requisitos funcionais so declaraes de funes que o sistema deve fornecer. Requisitos no funcionais se relacionam s propriedades emergentes do sistema e, portanto, se aplicam ao sistema como um todo. Requisitos de usurio so declaraes de alto nvel do que o sistema deve fazer. Requisitos de usurio devem ser escritos em linguagem natural, tabelas e diagramas. Requisitos de sistema se destinam a comunicar, de modo preciso, as funes que o sistema tem de fornecer. O processo de engenharia de requisitos inclui um estudo de viabilidade, elicitao e anlise de requisitos, validao de requisitos e gerenciamento de requisitos. A elicitao e a anlise de requisitos constituem um processo iterativo, envolvendo entendimento de domnio, coleta, classificao, estruturao, priorizao e validao de requisitos. O gerenciamento de requisitos inclui planejamento e gerenciamento de mudanas
27
28
estrutura do software em termos de componentes, sendo que, a partir de procedimentos de refinamento, chega-se a um nvel de especificao bastante prximo da codificao do programa. Sem dvida, o projeto de software se situa no ncleo tcnico da ES e representa uma atividade central, como afirma Mitch Kapor criador do software Lotus 1-2-3: O que projeto? onde voc se instala com um p em dois mundos o mundo da tecnologia e o mundo das pessoas e objetivos humanos e voc tenta juntar os dois... Pressman (2006) afirma que o projeto o que todo engenheiro deseja realmente fazer. Pois, so as atividades de projeto em que se pode aplicar criatividade e habilidade tcnica nas solues para os problemas que o software pretende resolver isto , os requisitos do cliente, as necessidades do negcio e as consideraes tcnicas se juntam na formulao de um produto. O projeto permite ao engenheiro modelar o produto que deve ser construdo. Esse modelo pode ser avaliado quanto qualidade e aperfeioado antes que o cdigo seja gerado, testes sejam conduzidos e usurios finais fiquem envolvidos em grande nmero. O projeto o lugar em que a qualidade do software estabelecida. O projeto facilita duas atividades que so essenciais no ciclo de vida de um sistema de software. Primeiro, ele possibilita a avaliao do sistema contra seus objetivos antes mesmo dele ser construdo. Dessa maneira, ele aumenta a confiana de que o sistema construdo, se de acordo com o projeto, alcanar seus objetivos. Obviamente, uma vez que nesse ponto h apenas o modelo de projeto, a avaliao no ser completa, mas isso tambm no quer dizer que ela no oferea resultados importantes que levem ao sucesso do sistema. J a outra atividade beneficiada pelo projeto a prpria construo do sistema, dado que ele tambm serve como guia para a implementao do software. Podemos observar que o projeto deve descrever diversos aspectos do software para que, assim, possibilite sua construo. Entre estes aspectos, esto: A estrutura esttica do sistema, incluindo a hierarquia de seus mdulos/ componentes/classes; A descrio dos dados a serem usados; Os algoritmos a serem usados; O empacotamento do sistema, em termos de como os mdulos esto agrupados em unidades de compilao; e As interaes entre mdulos, incluindo as regras de como elas devem acontecer e porque elas acontecem. Por fim, citamos uma definio de projeto que engloba todos estes aspectos: Projeto de software tanto o processo de definio da arquitetura, mdulos, interfaces e outras caractersticas de um sistema quanto o resultado desse processo. (SOMMERVILLE, 2007) importante deixar claro que o projeto de software evolui a partir do surgimento de novos mtodos de projeto e de anlise de software, por exemplo, o projeto depende do paradigma utilizado na modelagem do software (Orientado a objetos? Estruturado? Orientado a aspectos? Orientado a agentes?), depende de padres de projetos, etc. Assim, para quem vai atuar no desenvolvimento como engenheiro de software precisa estar sempre atualizado com as novas tecnologias que auxiliam as atividades de projeto.
29
durante a fase de diversificao em que as alternativas so geradas. Por alternativas, no nos referimos necessariamente a documentos descrevendo uma possvel soluo, mas tambm as ideias de soluo. Essas alternativas so solues em potencial e so geradas/obtidas a partir do conhecimento e da experincia do engenheiro responsvel pelo projeto. J na fase de convergncia, o responsvel escolhe a alternativa (ou combinao de alternativas) que satisfaz(em) aos objetivos e restries esperados. A escolha compor a soluo que se sujeitar s restries impostas pelo domnio do problema. Essa soluo ser descrita por meio de alguma representao e essa representao escolhida deve estar de acordo com seus propsitos: descrever a soluo e permitir a construo do sistema que melhor alcana os objetivos esperados. Do ponto de vista do gerenciamento do processo de desenvolvimento (SWEBOK, 2004), a etapa de projeto conduzida basicamente em dois principais estgios: O projeto de software preliminar, chamado de projeto arquitetural ou projeto de alto-nivel, o qual permite estabelecer, a partir dos requisitos, a arquitetura do software e da informao relacionada; O projeto de software detalhado, ou projeto de baixo-nivel, o qual permite aperfeioar a estrutura do software e definir representaes algortmicas de seus componentes (representao mais prxima da codificao do software).
No contexto dos projetos preliminar e detalhado, um conjunto de atividades tcnicas de projeto so desenvolvidas. Num ponto de vista mais genrico, pode-se destacar as atividades de desenvolvimento dos projetos arquiteturais, dos procedimentais e de dados. Falaremos um pouco mais a frente sobre esses projetos.
30
2.2.1 Abstrao
O princpio de abstrao est fortemente relacionado com as caractersticas de modularidade que um software pode apresentar. Quando se desenvolve um software que vai apresentar estas caractersticas, comum que suas representaes sejam feitas considerando vrios nveis de abstrao. No que diz respeito linguagem de representao, nos nveis mais altos de abstrao, a linguagem utilizada bastante orientada aplicao e ao ambiente onde o software ir ser executado. medida que se vai descendo nos nveis de abstrao, a linguagem de representao vai se aproximando de questes de implementao, at que, no nvel mais baixo, a soluo representada de modo a que possa ser derivada diretamente
31
para uma linguagem de implementao. Na realidade, o prprio processo de ES constitui-se num aprimoramento de nveis de abstrao. Na anlise de requisitos, a soluo em termos de software apresentada de forma conceitual. Durante o projeto, partindo do projeto preliminar para o projeto detalhado, mltiplos nveis de abstrao vo sendo definidos, aproximando-se cada vez mais da Implementao, que o nvel mais baixo de abstrao.
2.2.2 Refinamento
O refinamento surgiu na forma de uma tcnica de projeto (a tcnica de Refinamentos Sucessivos, proposta por Wirth em 1971). Esta tcnica sugere como ponto de partida a definio da arquitetura do software a ser desenvolvido, sendo que esta vai sendo refinada sucessivamente at atingir nveis de detalhes procedimentais. Este processo d origem a uma hierarquia de representaes, em que uma descrio macroscpica de cada funo vai sendo decomposta passo-a-passo at se obter representaes bastante prximas de uma linguagem de implementao.
32
independncia entre os mdulos, o que altamente desejvel num tal projeto. Os benefcios da adoo deste princpio vo aparecer no momento em que modificaes devero ser encaminhadas em nvel da implementao, por exemplo, por consequncia de uma atividade de teste do software. Graas ocultao de informao, erros introduzidos como resultado de alguma modificao num dado mdulo no sero propagados a outros mdulos do software.
Em Cincia da Computao, essa estratgia muito utilizada no projeto de algoritmos e, normalmente, instanciada atravs do uso de recurso, uma vez que os problemas devem ser decompostos e as solues dos subproblemas devem ser combinadas ao final da execuo para compor a soluo do problema inicial. Por exemplo, a deciso de organizar uma aplicao web em camadas nada mais que dividir um problema maior em diferentes nveis de abstrao, onde cada camada ser responsvel por implementar um servio mais bsico e especfico (apresentao, lgica de negcio e armazenamento). Vrios so os benefcios providos pela estratgia de diviso e conquista. No nosso exemplo, a diviso da arquitetura em camadas propicia a implementao de cada camada separadamente. Alm disso, as camadas podem ser tratadas como componentes reusveis de software, uma vez que implementam um servio nico e bem definido. Portanto, diviso e conquista tambm viabiliza o reuso de software.
33
tarefas realizadas dentro de um mesmo mdulo. As tarefas de um mdulo podem estar relacionadas entre si por diferentes motivos. Esses motivos so usados para classificar os diferentes tipos de coeso: Coeso funcional: as tarefas esto agrupadas por suas funes serem similares. Coeso sequencial: as tarefas esto agrupadas por elas pertencerem mesma sequncia de operaes. Elas compartilham dados a cada etapa da sequncia, mas no realizam uma operao completa quando executadas juntas. Coeso comunicativa: as tarefas esto agrupadas porque usam os mesmos dados, mas no esto relacionadas de nenhuma outra maneira. Coeso temporal: as tarefas esto agrupadas por serem executadas no mesmo intervalo de tempo. Coeso procedural: as tarefas esto agrupadas porque elas devem ser executadas numa ordem especfica. Coeso lgica: as tarefas esto agrupadas por compartilharem uma mesma flag de controle, que indicar qual tarefa ser realizada durante a execuo do sistema. Coeso coincidente: as tarefas esto agrupadas sem qualquer critrio.
Para alcanarmos bons projetos, podemos ordenar os tipos de coeso dos mais desejveis para os menos desejveis: funcional, sequencial, comunicativa, temporal, procedural, lgica, e coincidente.
34
objetivo no apresentar detalhes procedimentais ou de sequenciamento entre processos, mas de estabelecer as relaes entre os diferentes componentes do software, explicitando os nveis de abstrao (refinamento) aos quais eles pertencem. O modo mais usual de apresentar a hierarquia de controle utiliza uma linguagem grfica, normalmente em forma de rvore, como mostra a Figura 2.2. Com relao estrutura de controle importante apresentar algumas definies de medio. Utilizando a Figura 2.2 como referncia, possvel extrair alguns conceitos: a profundidade, a qual est associada ao nmero de nveis de abstrao definidos para a representao do software; a largura, que permite concluir sobre a abrangncia do controle global do software.
o fan-out, que permite definir a quantidade de mdulos controlados por um dado mdulo; o fan-in, que indica quantos mdulos controlam um dado mdulo.
Ainda, possvel estabelecer as relaes de controle entre os mdulos. Um mdulo que exerce controle sobre outros mdulos denominado o mdulo superordenado. Um mdulo que controlado por outro dito um mdulo subordinado a ele.
35
evidente que a construo de procedimentos de software uma atividade que deve ser feita tendo como referncia a hierarquia de controle. Isto porque, na definio do procedimento de um dado mdulo de software, deve ser feita referncia a todos os mdulos subordinados a ele. Normalmente, esta referncia ser desenvolvida, num nvel mais baixo de detalhamento, de modo a se obter o procedimento de software do mdulo subordinado.
36
procedimental do software (ou de seus componentes). O projeto dos dados nada mais do que a seleo das representaes lgicas dos objetos de dados identificados na etapa de anlise e especificao dos Requisitos. Como forma de obter resultados satisfatrios no que diz respeito ao projeto dos dados no contexto de um software, alguns princpios podem ser adotados: A realizao de uma anlise sistemtica no que diz respeito aos dados, a exemplo do que feito com os aspectos funcionais e comportamentais do software; Identificao exaustiva das estruturas de dados e das operaes a serem realizadas sobre elas; Estabelecimento de um dicionrio de dados (eventualmente, o mesmo definido na etapa de Anlise de Requisitos, incluindo refinamentos); Adiar decises de baixa prioridade no que diz respeito ao projeto de dados (aplicao do princpio de refinamentos sucessivos); Limitar a representao das estruturas de dados aos mdulos que as utilizaro; Estabelecimento de uma biblioteca de estruturas de dados teis e das operaes a serem aplicadas a elas (reusabilidade); Adoo de uma linguagem de programao e projeto que suporte tipos abstratos de dados.
2.4.2.1 Vises
Outro importante aspecto sobre a arquitetura de software que ela normalmente organizada em vises. Na ontologia estabelecida pela ANSI/IEEE 1471-2000, vises so instncias de pontos de vista, onde um ponto de vista existe para descrever a arquitetura na perspectiva de um conjunto de stakeholders e seus consortes. Algumas possveis vises so:
37
Viso funcional/lgica; Viso de cdigo; Viso de desenvolvimento/estrutural; Viso de concorrncia/processo/thread; Viso fsica/evolutiva; Viso de ao do usurio/feedback.
Vrias linguagens para descrio da arquitetura de software foram inventadas, mas nenhum consenso foi ainda alcanado em relao a qual conjunto de smbolos ou sistema representao deve ser adotado. Uma muito adotada quando desenvolvendo softwares orientados a objetos a UML (do ingls, Unified Modelling Language). Alguns exemplos de decises que ocorrem no projeto arquitetural so: Modularizao do projeto em subsistemas ou mdulos; Escolha de uma estrutura de comunicao e controle entre os subsistemas. Quem chama quem? Definio das interfaces entre subsistemas ou mdulos; Escolha de uma estratgia de persistncia; Escolha do paradigma de sistemas de banco de dados a usar; Determinao de oportunidades para o reuso de software; Atendimento a requisitos especiais de desempenho; Atendimento a outros requisitos (custo, mobilidade, uso de padres, etc.); Exposio das interfaces para facilitar a futura integrao de aplicaes (Enterprise Application Integration - EAI); etc.
38
estruturada, no encontra grandes dificuldades para combin-las durante a atividade de sntese de um dado procedimento. A mesma observao pode ser feita para as atividades de anlise.
2.4.3.2 O pseudocdigo
Esta notao pode ser aplicada tanto para o projeto arquitetural quanto para o projeto detalhado e a qualquer nvel de abstrao do projeto. O projetista representa os aspectos estruturais e de comportamento utilizando uma linguagem de sntese, com expresses de sua lngua (Ingls, Portugus, etc...), e estruturada atravs de construes tais como: IF-THEN-ELSE, WHILE-DO, REPEAT-UNTIL, END, etc... Esta poltica permite uma representao e uma anlise dos fluxos de controle que determinam o comportamento dos componentes do software bastante adequadas posterior derivao do cdigo de implementao. O uso do pesudocdigo pode suportar o desenvolvimento do projeto segundo uma poltica top-down ou bottom-up. No caso do desenvolvimento top-down, uma frase definida num dado nvel de projeto substituda por sequncias de frases que representam o refinamento da frase original. O pseudocdigo, apesar de no apresentar uma viso grfica da estrutura do software ou de seu comportamento, uma tcnica bastante interessante pela sua facilidade de uso e pela sua similaridade com algumas das linguagens de implementao conhecidas, como, por exemplo, Pascal, C, etc.
39
A Figura 2.5 apresenta alguns exemplos de blocos bsicos definidos nesta tcnica. A representao de comportamento obtida a partir do encaixe das estruturas bsicas, formando uma caixa como mostra o exemplo da figura 6.5.
40
Atividades prticas: representam questes simples e objetivas sobre o assunto aqui abordado. Na prtica, bastar estudar o assunto contido no captulo para respond-las corretamente. Atividades de pesquisas: representam tpicos de pesquisas dirigidos no muito extensos. Para cada tpico de pesquisa sugerido indicaremos fontes que podero auxiliar na pesquisa, mas voc ter total liberdade de consultar outras fontes caso deseje. Em cima do tpico sugerido, definimos algumas questes que devero ser respondidas. Sugerimos ainda que as atividades de pesquisa sejam feitas em equipe, pois isso favorece o aprendizado e enriquece a discusso sobre o assunto. Atividades de interao: correspondem atividades que visam discutir sobre o assunto nos fruns criados para o curso.
Como as atividades seguem o mesmo modelo do capitulo anterior, no forneceremos exemplos respondidos. Caso tenha duvidas a respeito consulte-nos! Estamos aqui para auxiliar uns aos outros na construo do saber.
41
software. Descreva que funcionalidades ela apresentam e a que paradigma de desenvolvimento de software elas correspondem.
Conhea Mais
Para conhecer um pouco mais sobre projeto de software h vrios livros e artigos disponveis, muitos deles so em ingls, seguem algumas boas sugestes. Recomendamos a leitura do Cap. 9 de Pressman (2006). Recomendamos a leitura do livro Software Design, de Budgen, aos interessados em mais informaes sobre a teoria em projeto de software. Dois artigos que apresentam discusses teis sobre o assunto so Software Design and Architecture The Once and Future Focus of Software Engineering, de Taylor e Van der Hoek, e Conceptual Foundations of Design Problem Solving, de Smith e Browne. Sobre arquitetura de software. Dissertao de mestrado. Disponvel em: <http:// www.ime.usp.br/dcc/posgrad/teses/ane.pdf>
42
Voc Sabia?
Veja algumas curiosidades atualizadas sobre Projeto de Software. Voc sabia que... A origem da arquitetura de software como um conceito foi primeiramente identificado no trabalho de pesquisa de Edsger Dijkstra em 1968 e David Parnas no incio de 1970. Estes cientistas enfatizaram a importncia das estruturas de um sistema de software e a criticidade da identificao da sua estrutura.[5] O estudo deste campo aumentou de popularidade desde o inicio de 1990 com os trabalhos de pesquisa concentrando-se nos padres de estilo de arquitetura, linguagens de descrio de arquitetura, documentao de arquitetura, e mtodos formais.[6] Muitas instituies de pesquisa tais como a Carnegie Mellon University e a University of California, Irvine estavam realizando muitas pesquisas no campo da arquitetura de software. Mary Shaw e David Garlan da Carnegie Mellon escreveram um livro intitulado Software Architecture: Perspectives on an Emerging Discipline em 1996, o qual trazia a tona conceitos da arquitetura de software, tais como componentes, conexes, estilos, etc. Os esforos do UCIs (Institute for Software Research) na pesquisa da arquitetura de software foram inicialmente direcionado para os estilos de arquitetura, descries de linguagens arquitetura, e arquiteturas dinmicas. Fonte: Wikipedia (arquitetura de software). Disponvel em: http://pt.wikipedia.org/wiki/ Arquitetura_de_software
Cinema em Ao
Para complementar o conhecimento que foi exposto neste captulo, voc pode acessar alguns vdeos-aula de apenas 10 minutos cada disponibilizado livremente na Internet (YouTube). O contedo claro, objetivo e correto. Vale a pena ser visto! Um vdeo bem curtinho cheio de humor falando sobre os requisitos exigidos para desenvolver o projeto preliminar do software (arquitetura). Disponvel em: <http://www. youtube.com/watch?v=rb2gstU2MrU> Vdeo descrevendo o perfil do arquiteto de software e guias para se tornar um. Disponvel em: <http://www.youtube.com/watch?v=Dx_nz_GM9s0&feature=related> Um vdeo em ingls falando sobre o projeto e arquitetura de software: <http://www. youtube.com/watch?v=79hrNLm6S7k&feature=related>
Vamos Revisar?
Resumo
O projeto de software se inicia quando a primeira iterao da engenharia de requisitos concluda. O objetivo do projeto aplicar um conjunto de princpios, conceitos e prticas que leva ao desenvolvimento de um sistema ou produto de alta qualidade, criar um modelo de software que vai implementar todos os requisitos do cliente de forma correta e trazer satisfao para os usurios dele. Nesse processo, deve-se examinar as vrias alternativas de projeto e convergir para uma soluo que melhor satisfaa s necessidades dos interessados no projeto.
43
44
Fundamentos dos testes de software; Classificao dos testes de software; Algumas atividades do processo de testes.
Verificao: o processo que garante que a estrutura e a lgica de uma soluo tratam eficazmente dos requisitos. Isto normalmente realizado em cada fase do processo de desenvolvimento de software. A verificao tambm pode implicar o fato de que a soluo foi desenvolvida de acordo com padres aceitos para tal. Em outras palavras, a verificao uma atividade que tem como objetivo assegurar consistncia, completude e corretude do produto em cada fase e entre fases consecutivas do ciclo de vida do software. A verificao faz a seguinte pergunta: A aplicao foi construda corretamente?. Podemos citar como exemplos de tcnicas de verificao as revises tcnicas e as lista de verificaes (do ingls, checklist). Validao: uma atividade que tem como objetivo assegurar que o produto final corresponda aos requisitos do software. Nesse caso, o objetivo da validao responder a pergunta Estamos construindo o produto certo?. Os testes funcionais e estruturais so considerados como tcnicas de validao do software. Testes: refere-se ao processo que testa as funes da soluo de software para garantir que estas funcionam correta e satisfatoriamente de acordo com padres de qualidade aceitos. Estes padres podem incluir confiabilidade, finalizao, desempenho, portabilidade, usabilidade e outras propriedades desejveis. Isto , testes representam um conjunto de atividades que tem como objetivo examinar o comportamento do produto atravs de sua execuo, alguns desses
45
Ateno
Lembre que um produto de software composto no apenas do software, mas de todos os artefatos produzidos como documentaes, manuais, diagramas, etc.
As atividades de verificao, validao e testes compem atividades caracterizadas como estticas e dinmicas, cujo objetivo avaliar os diversos artefatos de software, ou seja, os produtos intermedirios de software que so liberados ao longo do processo de desenvolvimento (ex. documento de requisitos, modelo de projeto, arquitetura, cdigo, manuais, etc). Essas atividades tambm esto diretamente associadas com a garantia da qualidade de software. Falaremos um pouco sobre isso do decorrer deste curso em fascculos posteriores, contudo, recomendamos que voc procure outras fontes de leitura, pois este assunto bem extenso, sendo impossvel abord-lo completamente em apenas alguns captulos. As atividades estticas esto associadas a uma avaliao das propriedades de qualidade do produto e no implicam na execuo do mesmo as atividades de verificao so desse tipo. Um exemplo de atividade esttica a reviso tcnica formal dos artefatos de software, pois esse tipo de atividade no implica na execuo do produto que est sendo validado o software (COWARD, 1988). Um exemplo prtico seria a reviso do documento de requisitos de software produzido pelas atividades de Engenharia de Requisitos, voc no precisaria do software executando para revisar esse documento e identificar possveis inconsistncias e/ou ambiguidades de requisitos. J no caso das atividades dinmicas, mandatria a execuo do produto de software, esse o caso das atividades de testes. Tem como testar o software sem execut-lo? Neste curso abordaremos, sobretudo, as atividades relativas aos testes, mas abordaremos brevemente algumas atividades de verificao.
46
A reviso tambm pode ser formal ou informal. Ela formal quando precisa seguir um srie de atividades formalizadas e obrigatrias para sua execuo, por exemplo, enviar convite formal para a reviso, ter uma reunio presencial, ter um nmero de pessoas fixo, etc. Esse o caso da tcnica de reviso chamada inspeo. Quando no precisa de formalidade, as revises tcnicas so chamadas de informais. Um exemplo simples quando voc est codificando e chama um colega para verificar se o que voc fez est correto. Para
47
reduzir custos, por exemplo, voc pode no precisar abrir mo das revises, e sim adot-las de maneira informal. Toda reviso seja ela formal ou no precisa de um planejamento para determinar pontos como: Quem participar da reviso? O engenheiro? O testador? O usurio? Voc precisa selecionar as pessoas que mais podero contribuir na reviso do artefato visando identificao de erros e falhas. necessria alguma informao antes da reviso? Os revisores precisam estudar algum documento? Existe alguma pr-condio que deve ser satisfeita antes que a reviso possa ser conduzida? Como Organizar? Onde, quando e em que horrio ser realizada? Os participantes estaro disponveis nesse horrio? recomendvel gerar ou adotar listas de pontos de verificao (do ingls, checklists) ou outra indicao do que deve ser coberto na reviso. Na Figura 3.1 h um exemplo de alguns itens de checklist para a reviso do documento de requisitos. Determinar as condies de trmino ou critrios que devem ser satisfeitos para que a reviso termine; Gerar registros e documentos que devem ser produzidos.
Respondendo a essas perguntas e realizando as atividades necessrias para operacionalizar a reviso, voc ento estar pronto para a reviso tcnica. Que tal voc experimentar a tcnica e fazer uma reviso informal com algum colega de algum cdigo que voc produziu durante os cursos? Experimente!
Checklist do documento de requisitos 1. O documento est livre de erros de concordncia e sintaxe? 2. Os requisitos so testveis? 3. A anlise do domnio da informao est completa, consistente e correta? 4. O particionamento do problema est completo? 5. As interfaces internas e externas esto definidas corretamente? 6. Os modelos de dados refletem os objetos, seus atributos e relacionamentos corretamente? 7. Todos os requisitos podem ser mapeados para o nvel de sistema? Figura 3.1 Alguns itens de checklist para revisar o documento de requisitos.
Vamos agora entender um pouco mais sobre duas tcnicas de reviso: o walkthroug e a inspeo. Ambas tem a mesma finalidade, a descoberta antecipada de falhas (produo de uma sada incorreta em relao especificao), de modo que eles no se propaguem para o passo seguinte do processo de software.
48
3.2.1 Walkthroug
Segundo Yourdon (2000), walkthrough representa uma reviso por pares, em grupo, de qualquer produto tcnico. O autor argumenta que essa reviso pode envolver tanto outros engenheiros de software quanto tambm usurios, programadores, analistas, projetistas, operadores e que possam estar envolvidos nos vrios aspectos do software sendo desenvolvido. Para Corliss (2001), walkthroughs so tcnicas prticas, simples e bem aceitas para a melhoria da qualidade do software. No walkthroug no h um conjunto de atividades a seguir para acontec-la, existem recomendaes ou boas prticas. Voc, por exemplo, terminando o seu cdigo, poderia consultar o lder da equipe e ver se ele teria disponibilidade para realizar com voc um walkthroug do cdigo que voc fez, sem muita formalidade na atividade, apenas focando na melhoria da qualidade do artefato de software produzido.
3.2.2 Inspeo
O processo de inspeo foi descrito primeiramente por Michael Fagan (1986) e composto por seis fases, que so: planejamento, apresentao, preparao, reunio de inspeo, retrabalho e acompanhamento. No planejamento os inspetores so selecionados e os materiais a serem revisados so preparados; na apresentao, o grupo recebe instrues essenciais sobre o material a ser inspecionado, especialmente sobre o que deve ser inspecionado; na preparao, integrantes do time de inspeo se preparam para desempenhar o papel designado a cada um; no momento da reunio de inspeo os defeitos so encontrados, discutidos e categorizados; no retrabalho o autor do documento corrige os defeitos encontrados pelo time de inspeo e na etapa de acompanhamento, o time de inspeo responsvel por assegurar que todos os defeitos encontrados foram corrigidos e nenhum outro tipo de defeito foi introduzido na fase de retrabalho. Um grupo de inspeo envolve desenvolvedores de software, entre outros participantes, em um processo formal de investigao. Consiste de trs a oito participantes e inclui os seguintes papis: o autor que o desenvolvedor do produto a ser inspecionado; o moderador que o membro da equipe que lidera a inspeo, programa e controla as reunies, o redator que aquele que tem como funo relatar os defeitos (passo, processo ou definio de dados incorretos, como por exemplo, uma instruo ou comando incorreto) e as questes surgidas durante a inspeo e o inspetor que o papel assumido por cada integrante do time de inspeo que tenta encontrar erros no produto, sendo que todos os participantes podem agir como inspetores alm de executarem outras atribuies. A inspeo o processo de reviso de software mais formal que existe. Ela exige que todas as fases sejam executadas e todos os procedimentos seguidos.
49
preocupao em aprimorar e aperfeioar os processos de testes em desenvolvimento de software com vistas a reduzir custos com manuteno e em produzir um produto de melhor qualidade.
O teste consiste em executar o programa com a inteno de encontrar erros. (MYERS, 1979) Dentre os principais objetivos do processo de teste temos: Verificar se todos os requisitos do software foram corretamente implementados; Assegurar, na medida do possvel, a qualidade e a corretude do software produzido; Reduzir custos de manuteno corretiva e retrabalho; Assegurar a satisfao do cliente com o produto produzido; Produzir casos de teste que tenham elevada probabilidade de revelar um erro ainda no descoberto, com uma quantidade mnima de esforo e tempo; Comparar o resultado dos testes com os resultados esperados a fim de produzir uma indicao da qualidade e da confiabilidade do software; Verificar a correta integrao entre todos os componentes do software. Naturalmente o assunto no to simples assim, pois: Erros nem sempre so bvios; Erros diferentes podem ter a mesma manifestao; Saber que um programa no esta correto no necessariamente saber como corrigir o erro.
A realizao, com sucesso, da etapa de teste de um software deve ter, como ponto de partida, uma atividade de projeto dos casos de teste deste software. Projetar casos de teste para um software pode ser uma atividade to complexa quanto a de projeto do prprio software, mas ela necessria como nica forma de conduzir, de forma eficiente e eficaz, o processo de teste.
50
Caso de teste: representam cenrios de teste em que especificam as entradas e sadas esperadas. Mostra os caminhos percorridos por um mdulo, caso de uso ou funcionalidade dentro do projeto. Servem como base para que os testadores possam executar os testes e devem cobrir o mximo de situaes possveis. Um exemplo de caso de teste ilustrado na Figura 3.2. Segunda a norma IEEE 829 um caso de teste deve possuir: Identificador Itens de teste: breve descrio dos itens, funcionalidades, mdulos, etc. que ser descrito no caso de teste. Especificaes de entrada: especifica todas as entradas necessrias para executar o caso de teste. Podemos colocar qualquer tipo de entrada no caso de teste, o que melhor se adequar a sua realidade. Ex: dados na tela, comandos SQL, mensagens, etc... Especificaes de sada: especificar todas as saidas e particularidades depois de executada uma determinada entrada. Procure explicar claramente o que deve ser exibido para no haver erros de entendimento. Ambiente necessrio: especifica os ambientes como hardware e software necessrios para a execuo do caso de teste, bem como qualquer configurao que externa (fora da aplicao). Exigncias especiais: descreve qualquer caso especial de inicializao, configurao, etc que seja necessrio aplicar no caso de teste.
Exemplo de caso de teste
Identificador: <Caso de Teste 0> - <Teste de Fazer Login>: Descrio: O usurio (discente) deve ser capaz de fazer login no sistema e assim ter acesso s opes de discente do sistema. Pr-condies: O sistema deve estar disponvel e operante. Entrada: Os dados utilizados nesta operao so: a matrcula e senha do discente. Sada: Aps o login ser bem-sucedido, o usurio deve ter acesso s opes de discente do sistema. Caso o login falhe dever ser apresentado uma notificao e o usurio ter que repetir a operao. Ambiente necessrio: ter uma mquina conectada a internet. Exigncias especiais; --Figura 3.2 Exemplo de caso de teste.
51
assunto teste de software e que descrevem os fundamentos e princpios desta atividade, esto relacionados abaixo: Conforme a Lei de Pareto, 80% dos erros podem ser localizados em 20% do projeto, geralmente nos mdulos principais do sistema; A atividade de teste no prova a ausncia de erros, apenas a existncia dos mesmos; Bons casos de teste so aqueles que encontram falhas no sistema at ento no descobertas; Bons casos de teste so projetados levando em conta os requisitos do projeto; Um critrio que pode ser utilizado para determinao do esforo a ser gasto na atividade de teste de software verificar qual o grau de severidade das consequncias advindas do seu mau funcionamento; A probabilidade de encontrar um erro numa determinada parte do sistema proporcional ao nmero de erros j encontrados nesta parte; A maior parte dos autores concorda que os programas devem, preferencialmente, ser testados por pessoas no envolvidas no processo de desenvolvimento, por uma equipe independente. Pode haver tambm a interao dos desenvolvedores com a equipe independente, justificando as decises tomadas durante o projeto. Esta abordagem ajuda na reviso do projeto.
Os princpios bsicos do teste de qualquer produto resultante de uma tarefa de engenharia so: Conhecida a funo a ser desempenhada pelo produto, testes so executados para demonstrar que cada funo completamente operacional, este primeiro princpio deu origem a uma importante abordagem de teste, conhecida como o teste de caixa preta (do ingls, black box); Com base no conhecimento do funcionamento interno do produto, realiza-se testes para assegurar de que todas as peas destes esto completamente ajustadas e realizando a contento sua funo; abordagem originada por este segundo princpio, foi dado o nome de teste de caixa branca (do ingls, white box), devido ao fato de que maior nfase dada ao desempenho interno do sistema (ou do produto).
Quando o procedimento de teste est relacionado ao produto de software, o teste de caixa preta refere-se a todo teste que implica na verificao do funcionamento do software atravs de suas interfaces, o que, geralmente, permite verificar a operacionalidade de todas as suas funes. importante observar que, no teste de caixa preta, a forma como o software est organizado internamente no tem real importncia, mesmo que isto possa ter algum impacto na operao de alguma funo observada em sua interface. Um teste de caixa branca num produto de software est relacionado a um exame minucioso de sua estrutura interna e detalhes procedimentais. Os caminhos lgicos definidos no software so exaustivamente testados, pondo a prova conjuntos bem definidos de condies ou laos. Durante o teste, o status do programa pode ser examinado diversas vezes para eventual comparao com condies de estado esperadas para aquela situao.
52
sendo agrupados em duas categorias. Um relativo ao alvo destino do teste. Neste primeiro grupo se encontra os testes de unidade, os testes de integrao e os testes de sistemas. O segundo grupo se refere ao objetivo final dos testes, por exemplo, testes de aceitao, testes de instalao, testes alpha e beta, testes de regresso, testes de conformidade, dentre outros, que varia de acordo com o tipo de software. Explanaremos alguns desses testes.
53
54
e ampliar a organizao e controle dos projetos de testes, que como as demais atividades do desenvolvimento tambm no so to triviais assim. Como qualquer outro processo, ele deve ser revisto continuamente, de forma a ampliar sua atuao e possibilitar aos profissionais uma maior visibilidade e organizao dos seus trabalhos, o que resulta numa maior agilidade e controle operacional dos projetos de testes. Por se tratar de um processo propriamente, as atividades de testes podem seguir muitos modelos de processos. Um muito divulgado na literatura, o modelo em V ilustrado na Figura 3.3, que se preocupa em executar os testes durante todo o ciclo de desenvolvimento com objetivo de encontrar erros o mais cedo possvel.
O modelo em V introduz a criao de testes de dados e cenrios de teste durante o ciclo de desenvolvimento do software e trabalha com diferentes nveis de testes como: teste de unidade, teste de integrao, teste de sistema e teste de aceitao. Isso significa que dependendo da fase ou momento do desenvolvimento, certos tipos de testes so mais indicados. Por exemplo, durante a codificao dos mdulos ou componentes do software, so realizados os testes de unidades. Quando essas unidades forem testadas e aprovadas, passa-se para a etapa de integrao dos componentes a fim de desenvolver o produto final e nesse momento os testes de integrao devem ser aplicados. Aps essa etapa, tem-se o software e a, os testes de sistemas so executados, tendo como referncia o que foi definido no projeto desse software. Por ltimo, ficam os testes de aceitao que so realizados para validar o software para entrega ao cliente. Como podemos notar tambm a base para os testes de software o documento de requisitos do sistema a partir dos quais so gerados os cenrios de testes e dos quais derivam os casos de testes (Figura 3.4). importante mencionar que quando a especificao dos requisitos baseada em cenrios atravs de casos uso, a especificao dos casos de testes normalmente facilitada, pois os casos de uso j especifica muitos fluxos alternativos e restries do cenrio de uso do software.
55
Uma sugesto para as atividades e etapas do processo de teste ilustrado na Figura 3.5. Temos trs principais etapas: uma para preparao dos testes em que se realiza o planejamento e especifica os casos de testes; seguido pela execuo propriamente dita; e finalmente, fechando com os registros dos testes. O que se observa, normalmente, que esse ciclo se repete at que todo software tenha sido testado e aceito pelo cliente.
A relao do processo de teste de software com o processo de desenvolvimento de software est representando no esquema apresentado na Figura 3.6. O planejamento dos testes se inicia com o plano de projeto e interage com o desenvolvimento no momento da especificao de requisitos e na liberao das verses a testar do software.
56
Atividades Prticas
1. Qual a diferena entre verificao e validao do software? Resposta: A verificao - Estamos construindo certo o produto.- feita para garantir que
57
as funcionalidades especificadas e definidas no DRS esto sendo implementadas no software. Esta atividade pode usar os seguintes mtodos:inspees, lista de verificao;simulaes;prova de corretitude. A validao - Estamos construindo o produto certo - Garante que o software que foi construdo atende os requisitos do cliente. Para realizar esta atividade podemos usar os seguintes mtodos: teste de caixa preta ou funcional, teste de caixa branca ou estrutural; teste de caixa cinza, anlise baseada em erros. 2. Elabore um planejamento de reviso para um dos pontos de verificao (checkpoint) apresentados no Quadro 3.1. Defina os seguintes pontos: Quem participa? Qual informao requerida antes da reviso? Pr-condies que devem ser satisfeitas antes que a reviso possa ser conduzida; Checklist ou outra indicao do que deve ser coberto na reviso. Condies de trmino ou critrios que devem ser satisfeitos para que a reviso termine; Registros e documentos que devem ser produzidos.
Resposta: Supondo que a equipe formada por engenheiros de softwares, arquitetos de softwares, testadores e analistas de requisitos, a reviso do projeto preliminar (arquitetura) seria planejada assim: Participantes: engenheiro de software, arquiteto de software, testador, analista de requisitos. O engenheiro dever ser o responsvel por registrar os erros encontrados e o analista ser o moderador da reunio. Informao requerida antes da reviso: todos os participantes devem conhecer os requisitos e restries do software Pr-condio: o autor do documento de projeto preliminar deve garantir que este estar disponvel a todos os participantes antes da reviso, pelo menos 4 horas antes Condies de trmino: at que todo documento de projeto preliminar tenha sido revisado e ainda no se passaram 2 horas de reunio. Aps esse tempo a reviso deve ser concluda, e uma nova reunio marcada para continuar a reviso da parte que resta revisar. Registro: ao final da reunio de reviso dever ser produzida uma lista com todos os erros e inconsistncias encontrados no projeto preliminar. Checklist para o projeto preliminar:
Os requisitos do software esto refletidos na arquitetura? A modularidade foi alcanada de maneira eficaz? Os mdulos so funcionalmente independentes? Foram definidas as interfaces dos mdulos e dos elementos externos do sistema? As estruturas de dados so consistentes com o domnio da informao?
58
As estruturas de dados so consistentes com os requisitos do software? O item manutenibilidade foi considerado? Outros fatores de qualidade foram explicitamente considerados?
Uma vez mostrados alguns exemplos de atividades respondidas, na prxima seo passemos as atividades propostas a serem respondidas por voc e colegas de curso.
c. ( ) Analisadores estticos so pessoas pouco dinmicas, mas que contribuem para o trabalho de inspeo de software. d. ( ) necessrio que um programa seja inteiramente livre de defeitos antes de ser entregue ao cliente. e. ( ) A confiabilidade do sistema depende do nmero de entradas que provocam sadas errneas durante o uso normal do sistema. f. ( ) Um sistema pode conter defeitos conhecidos, mas ainda assim ser considerado confivel pelos seus usurios. ) Em sistemas crticos as falhas tero um custo muito elevado. ) Em sistemas crticos a maior preocupao a eficincia.
g. ( h. ( i. j.
( ) No necessrio que um programa seja inteiramente livre de defeitos antes de ser entregue ao cliente. ( ) Testes devem ser feitos por outra pessoa ou equipe, no aquela que produziu o programa.
2) Elabore um planejamento de reviso para um dos pontos de verificao (checkpoint) apresentados no Quadro 3.1. Defina os seguintes pontos de planejamento: Quem participa? Qual informao requerida antes da reviso? Pr-condies que devem ser satisfeitas antes que a reviso possa ser conduzida; Checklist ou outra indicao do que deve ser coberto na reviso. Condies de trmino ou critrios que devem ser satisfeitos para que a reviso termine; Registros e documentos que devem ser produzidos.
59
3) Por que as empresas de software deveriam dedicar maior esforo verificao e validao? Discuta tambm as diferenas entre validao e verificao e explique por que a validao um processo particularmente difcil. 4) Tendo como base o sistema moodle de ensino distncia que voc utiliza para realizar este curso, escolha dois dos cenrios abaixo, e construa casos de testes para eles. a. Realizar o login no sistema moodle (senha vlida e senha invlida); b. Fazer matricula em curso c. Participar de um chat da disciplina d. Enviar um email e. Participar de um frum de discusso
60
Conhea Mais
Para conhecer mais profundamente sobre testes de software, voc pode consultar os stios abaixo relacionados. Comunidade que discute sobre validao e verificao do software. Disponvel em: <http://www.via6.com/comunidade.php?cid=8411> Para saber mais sobre casos de testes. Disponvel em: <http://www.wthreex.com/rup/ process/modguide/md_tstcs.htm> Leia o texto da Wikipdia sobre testes de software. Disponvel em: <http:// pt.wikipedia.org/wiki/Teste_de_software> Artigo em portugus falando sobre processos de testes. Disponvel em: <http://
imasters.uol.com.br/artigo/6118/des_de_software/processo_de_teste_de_software_ parte_03/>
Cinema em Ao
Para complementar o conhecimento que foi exposto neste captulo, voc pode acessar alguns vdeos-aula de apenas 10 minutos cada disponibilizado livremente na Internet (YouTube). O contedo claro, objetivo e correto. Vale a pena ser visto! Vdeo-aula sobre teste e manuteno de software. Disponvel em: http://www.youtube. com/watch?v=G6yk7fLK3JY
Vamos Revisar?
Resumo
As atividades de verificao, validao e testes de softwares so fundamentais para a garantia de qualidade do software. A verificao se preocupa em responder se o software est sendo construdo corretamente enquanto a validao foca em validar se o que est sendo construdo o correto. E os testes focam na descoberta de erros em funo das funcionalidades e restries. H diversos tipos de testes, estes so selecionados durante o planejamento de testes e dependem do tipo de software sendo produzido. O processo de teste complexo e exige planejamento e controle para ser realizado de forma eficaz.
61
Referncias
BEZERRA, E. Princpios de Anlise e Projeto de Sistemas com UML. [S.l]:Campus, 2002. BUDGEN, D. Software Design. 2nd Edition, Addison Wesley, 2003 CORLISS. Walkthroughs. UM COSC 198 Software Testing. Summer, 2001. Online. Atualizado em 2001. Disponvel no endereo: http://www.eng.um.edu/
corlissg/198.2001/walkthrough.html
IEEE Computer Society (online). Disponivel em: <http://www.computer.org/portal/ web/guest/home> LISLE, L.; Dong, J.; Isensee, S. Case study of developmente of and ease of use web site. Proceedings of human factors & the web conferences, 1998. Online. Data de atualizao no fornecida. Disponvel no endereo: http://www.research.att.com/
conf/hfweb/proceedings/lisle/
MYERS, Glen. The art of software testing. New York : J. Wiley, 1979 OSLON, T. How to improve your software inspection process. SEPG 99 Conference. Online. Atualizado em 1999. Disponvel no endereo: http://www.sercenter.com/KP/
qa/SQAtutorial.pdf
PRESSMAN, R.S. Engenharia de Software. 6 edio, [S.l]:McGraw-Hill, 2006. SEI: Software Engineering Institute (online). Disponivel em: <http://www.sei.cmu. edu/> SEI-CMM-3-1.5. The software review process. Online. Data de atualizao no disponvel. Disponvel no endereo: http://www2.umassd.edu/SWPI/curriculummodule/
cm3.pdf
SOMMERVILLE, I. Engenharia de Software. 6 edio, [S.l]:Pearson, 2007. SOMERVILLE, I. e KOTONYA, G., Requirements Engineering: Processes and Techniques, John Wiley & Sons, (1997). SOARES, A. L.. Introduo, Identificao e Anlise em Engenharia de Requisitos. Antnio Lucas Soares. 2005. SMITH, G. F.; BROWNE, G. J.. Conceptual Foundations of Design Problem Solving. Systems, Man and Cybernetics, IEEE Transactions on, 23(5), 12091219, 1993. TAYLOR, R. N.; VAN DER HOEK, A. Software Design and Architecture The Once and Future Focus of Software Engineering. In FOSE 07: 2007 Future of Software Engineering. (p. 226243). Washington, DC, USA: IEEE Computer Society, 2007. THAYER, T; DORFMAN, M. Software Requirements Engineering. R. H. Thayer, M. Dorfman. IEEE Computer Society Press. 1993. YOURDON, E. Walkthroughs and inspections. Modern Structured Analysis, 2nd edition, chapter 1. Online. Atualizado em 2000. Disponvel no endereo: http://www.
yourdon.com/books/msa2e/APPd/APPd.html
62
Consideraes Finais
Ol, cursista! Esperamos que voc tenha aproveitado este segundo volume da disciplina Fundamentos da Engenharia de Software. Na prxima unidade, continuaremos estudando algumas das reas de conhecimento base para a Engenharia de Software, particularmente a parte da gesto do projeto de software e a gerncia de configurao. Continue conosco! Aguardamos sua participao na prxima unidade.
graa divina comear bem. Graa maior persistir na caminhada certa. Mas graa das graas no desistir nunca. (Dom Helder Camara)
63
Conhea a Autora
Danielle Rousy Dias da Silva
Graduada em Cincias da Computao pela Universidade Federal da Paraba/UFPB (1998), com mestrado em Computao Inteligente, especialidade Inteligncia Artificial aplicada a Jogos Digitais, pela Universidade Federal de Pernambuco/UFPE (2000). Recm doutora tambm pela UFPE tendo como tema principal de pesquisa o uso de Atores Sintticos em Jogos de Treinamento para Adultos. Desde 2006, atua, sobretudo, como Engenheira de Qualidade na pesquisa e definio de processos de desenvolvimento de jogos mveis. J atuou exercendo diversos papis, entre eles o de Engenheira de Software na Meantime Mobile Creations e tambm no C.E.S.A.R (Centro de Estudos e Sistemas Avanados do Recife). Atualmente, trabalha em EAD como professora executora e conteudista e atua como Gerente de Projetos no desenvolvimento de jogos srios.
64