Fes Vol Ii

UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO (UFRPE)
COORDENAO GERAL DE EDUCAO A DISTNCIA (EAD/UFRPE)
Fundamentos da Engenharia de Software
Danielle Rousy Dias da Silva
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)
Bons estudos! Danielle R. D. da Silva Autora
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.
Mdulo 2 reas de Conhecimento Base da Engenharia de Software

Carga Horria do Mdulo 2: 15 h/aula
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.
Contedo Programtico do Mdulo 2:

Engenharia de requisitos; Anlise e projeto de software; Verificao, validao e teste de software.
Captulo 1 Engenharia de Requisitos

Vamos conversar sobre o assunto?
Um dos problemas mais comuns encontrados nos softwares ainda hoje est relacionado direta ou indiretamente com a dificuldade de especificar corretamente os requisitos do software. Por exemplo, comum encontrarmos softwares com requisitos especificados incorretamente ou com especificaes incompletas. Dessa forma, a fase de levantamento de requisitos, normalmente encontrada nos ciclos de desenvolvimento do software, assume um importante papel na qualidade final do produto, e destinada a melhorar os resultados dessa fase em que a Engenharia de Requisitos aplicada. Neste captulo explanaremos do que se trata a Engenharia de Requisitos e qual o seu papel no ciclo de desenvolvimento de software. Voc conhecer sobre: O que Engenharia de Requisitos (ER); Qual o seu papel dentro do ciclo de desenvolvimento do software; O que um requisito de software e quais seus tipos; Quais as fases de atividades associadas a especificao de requisitos.
1.1 Requisitos de Software

Vimos no fascculo anterior que o desenvolvimento de software complexo por natureza. Muito dessa complexidade est associada especificao do que o software ir fazer. Entenda como requisito neste caso a definio das necessidades e restries do software que contribuem para a soluo de algum problema real do mundo, por exemplo, os requisitos que voc utiliza para acessar o ambiente virtual deste curso como envio/leitura de email, chat, envio de tarefas, etc. Existem diferentes definies encontradas na literatura tcnica para requisitos: Um requisito uma caracterstica do sistema ou a descrio de algo que o sistema capaz de realizar para atingir os seus objetivos;
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).
Figura 1.1 Tipos de requisitos e seus interessados.
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.
1.1.1 Requisitos Funcionais

So requisitos diretamente ligados a funcionalidade do software, descrevem as funes que o software deve executar. Por exemplo, considerando o software que voc utiliza para realizar este curso (moodle), alguns exemplos so: O software deve permitir o cadastro dos alunos, tutores e professores; O software deve permitir a gerao de relatrios sobre o desempenho dos alunos, tutores e professores no semestre; O software deve permitir o envio/recebimento de mensagens eletrnicas. Outros exemplos de requisitos funcionais so: O software deve possibilitar o clculo dos gastos dirios, semanais, mensais e anuais com pessoal; O software deve emitir relatrios de compras a cada quinze dias; Os usurios devem poder obter o nmero de aprovaes, reprovaes e trancamentos em todas as disciplinas por um determinado perodo de tempo.
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.
1.1.2 Requisitos No-funcionais

So requisitos que expressam condies que o software deve atender ou qualidades especficas que o software deve ter. Em vez de informar o que o sistema far, os requisitos no-funcionais colocam restries no software, como manutenibilidade, usabilidade, desempenho, custos e vrias outras. Alguns exemplos so: O software deve ser compatvel com os browsers IE (verso 5.0 ou superior) e Firefox (1.0 ou superior); O software deve garantir que o tempo de retorno das consultas no seja maior do que 5 segundos. A base de dados deve ser protegida para acesso apenas de usurios autorizados. O tempo de resposta do sistema no deve ultrapassar 30 segundo. O software deve ser operacionalizado no sistema Linux.
O tempo de desenvolvimento no deve ultrapassar seis meses.
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
Completa Correta Compreensvel Consistente Concisa Confivel
Para Refletir...
Construir um sistema de software com base em requisitos inconsistentes e mal definidos como construir uma casa sem alicerce na areia...
1.2 Engenharia de Requisitos (ER) e Engenharia de Software (ES)

O processo de definio de requisitos uma interface entre os desejos e necessidades dos clientes e a posterior implementao desses requisitos em forma de software, e compreendem uma das primeiras atividades do ciclo de produo de um software. Entender as necessidades e atender os desejos dos clientes sempre foi colocado como um dos maiores desafios da Engenharia de Software. A postura da Engenharia de Requisitos a de prover ao Engenheiro de Software mtodos, tcnicas e ferramentas que auxiliem o processo de compreenso e registro dos requisitos que o software deve atender. Diferentemente de outras subreas da engenharia de software, a rea de requisitos tem que lidar com conhecimento interdisciplinar envolvendo,muitas vezes, aspectos de cincias sociais e cincia cognitiva, pois voc precisar saber lidar e compreender pessoas os requisitos partiram delas e chegaram a elas em forma de software.
Voc sabia que...

A rea de Engenharia de requisitos uma subrea da Engenharia de Software e surgiu em 1993 com a realizao do I International Symposium on Requirements Engineering.
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
Figura 1.2 Engenharia de requisitos (ER).
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
Figura 1.3 Entrada e sada do processo de ER.
1.3 Ponto de partida para um processo de ER

Segundo o SWEBOK (2004), o processo da ER precisa ser definido segundo os seguintes pontos: Definio do ciclo de vida do processo de ER: este ponto se refere definio de como as atividades de elicitao, anlise, especificao e validao de requisitos sero executadas. A ideia semelhante ao ocorrido na definio do processo de desenvolvimento de software comentado no fascculo I, voc se recorda? Por exemplo, para um software em que os requisitos ainda no so claros nem para o cliente nem os usurios, poderia ser definido um ciclo de vida interativo e incremental ou um ciclo baseado em prototipao, em que pequenos conjuntos de requisitos so elicitados, analisados, especificados e validados de forma incremental at que os requisitos do software estejam completamente especificados. importante ressaltar que a definio do ciclo ou modelo de processo est estritamente ligada com a anlise do software a ser produzido, se ele critico? Se embarcado? Se de automao? Se um jogo? etc Identificao dos atores: este ponto se trata da definio das pessoas que estaro envolvidas direta ou indiretamente no processo de ER, como por exemplo, os engenheiros de software, testadores, clientes, usurios, arquitetos, etc. E em que atividades e fases do processo de ER esses atores estaro envolvidos e pelo que sero responsveis. Definio dos processos de suporte e gerenciamento ao processo de ER: todo processo necessita definir mecanismo que possibilitem o gerenciamento e controle da execuo e resultados das atividades deles. Normalmente isto feito adotando processos secundrios que do suporte ao gerenciamento. Por exemplo, voc j imaginou como so gerenciados os requisitos do software que so liberados em
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.
1.4 Processo Genrico da ER

De uma forma geral, podemos estabelecer um processo genrico contendo as atividades mais comuns encontradas como as apresentadas na Figura 1.4. Essas atividades so encontradas, por exemplo, no especificado por (PRESSMAN, 2006; SOMMERVILLE, 2007; SOARES, 2005) para essa subrea da Engenharia de Software. No existe um processo ideal de engenharia de requisitos, mas no geral, possuem a seguinte ordem: inicia-se com a elicitao de requisitos, juntamente com anlise de requisito seguida das negociaes. Aps essas fases, os requisitos so documentados e validados. Paralelamente a todas essas atividades realizado o gerenciamento de requisitos que consiste em administrar as inevitveis mudanas dos requisitos propostos. O intuito com isso ter ao final os requisitos acordados com os interessados no sistema e a especificao dos requisitos. Normalmente o que se observa na indstria de software que a especificao dos requisitos de software quase sempre feita de forma interativa e incremental durante o ciclo de desenvolvimento de software, isto , os requisitos so desenvolvidos em pequenos pedaos.
13
Figura 1.4 Fases e atividades do processo de ER.
1.4.1 Elicitao de Requisitos

Essa primeira fase normalmente executada pelo engenheiro de requisitos ou de software ou analista juntamente com outros stakeholders do projeto de software (clientes, e demais pessoas interessadas e candidatas a usurias do software a ser produzido). Neste caso, o engenheiro de requisitos utiliza alguma ou um conjunto de tcnicas para descobrir (elicitar) os requisitos do software a ser desenvolvido, incluindo as informaes do negcio ou problema que restringem este software. Algumas das tcnicas mais conhecidas so: tcnicas de leitura de documentos, observao, entrevistas, reunies, questionrios, antropologia, participao ativa dos atores e engenharia reversa. Iremos falar de algumas dessas tcnicas ainda nesse volume.
Voc sabia que...

O termo stakeholder compreende todos os envolvidos em um processo, que pode ser de carter temporrio (como um projeto) ou duradouro (como o negcio de uma empresa ou a misso de uma organizao). No caso do desenvolvimento de software so, por exemplo, os desenvolvedores, gerentes, clientes e usurios.
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.
1.4.1.1 Algumas tcnicas de elicitao de requisitos

As tcnicas de elicitao de requisitos so divididas em formais e informais, onde as tcnicas que pressupem a construo de um modelo formal, conceitual do problema que est sendo analisado ou de um prottipo do produto a ser construdo so consideradas formais, e as tcnicas que se baseiam em interaes com o usurio/cliente e comunicao estruturada so consideradas informais. Dentre as principais tcnicas temos: a) Entrevista: a tcnica mais comum e mais utilizada na coleta de fatos, pois nada mais do que a comunicao entre entrevistado (cliente, por exemplo) e entrevistador (engenheiro ou analista, por exemplo). Segundo Kotonya (1998), h basicamente dois tipos de entrevista: a) entrevistas fechadas onde o engenheiro de requisitos procura as perguntas para um conjunto pr-definido de questes; b) entrevistas abertas onde no h agenda pr-definida e o engenheiro de requisitos discute, de modo aberto, o que os usurios querem do sistema. Na Figura 1.5, mostramos algumas questes normalmente encontradas quando se usa essa tcnica para elicitar os requisitos.
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:
Voc sabia que...

Os casos de uso foram definidos por Ivar Jacobson, tendo sido adotados pela linguagem UML (Unified Modeling Language), a qual tem sido considerada uma linguagem de modelagem padro para a especificao de sistemas de software orientados a objetos.
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.
1.4.2 Anlise e negociao de requisitos

Aps descobrir os requisitos do software, passa-se para a fase de anlise e negociao de requisitos, essa fase tambm no muito trivial e exige muita experincia e maturidade dos engenheiros responsveis por ela. Nesta fase o objetivo : Identificar e resolver conflito entre os requisitos Definir os limites do software e como ele interagir com o ambiente no qual ser inserido Derivar os requisitos de software
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.
1.4.3 Documentao dos requisitos

Esta atividade est relacionada com a descrio detalhada do sistema e dos requisitos do software, na forma de um documento, que usado para registrar os requisitos dos stakeholders. Muitas vezes, essa atividade intercalada com as atividades de elicitao, anlise e negociao dos requisitos. Segundo Somerville e Kotonya (1997), o documento de requisitos descreve: 1. Os servios e as funes que o sistema deve prover; 2. As limitaes sobre as quais o sistema deve operar e as limitaes nos processos usados para desenvolver o sistema;
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
Figura 1.6 Esboco dos SRS segundo diversos modelos.
1.4.4 Validao e verificao de requisitos

Na atividade de validao de requisitos a preocupao que os requisitos estejam definidos corretamente e assegurar que os requisitos satisfaam as necessidades dos stakeholders e clientes. Existem diferentes meios para a verificao no processo de validao de requisitos, mas os grandes destaques so: a verificao de novas ou diferentes funes no sistema; verificao de consistncia; verificao na documentao de requisitos que definem todas as funes e restries do sistema; e verificao se os requisitos podem realmente ser implementados utilizando uma determinada tecnologia existente. Para a verificao dos requisitos, existe uma srie de tcnicas que podem ser utilizadas, tais como: 1. Revises de requisitos: os requisitos so analisados por uma equipe de revisores, que analisam, discutem e apontam caminhos para solucionar problemas encontrados; 2. Prototipao: um modelo executvel mostrado aos usurios finais e clientes para demonstrar uma melhor representao dos requisitos do sistema; 3. Gerao de casos de teste: os requisitos so testados para garantir a validade dos requisitos. Se existem dificuldades em projetar o sistema, significa que os requisitos possuem problemas e devem ser reconsiderados.
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.
1.4.5. Gerenciamento de requisitos

Gerenciamento de requisitos o processo para compreender e gerenciar as mudanas de requisitos que ocorrem no sistema (SOMERVILLE e KOTONYA, 1997). Por este motivo, esta atividade uma das mais importantes no processo de engenharia de requisitos. A rastreabilidade uma forma de identificar os requisitos a serem alterados. Segundo (Pinheiro, 2000), o processo de desenvolvimento de software deixa rastros cuja identificao e acompanhamento funo da rastreabilidade. Assim, ele define rastreabilidade de requisitos como a habilidade de definir, capturar e seguir os rastros deixados pelos requisitos nos outros elementos do ambiente de desenvolvimento de software e os rastros deixados por esses elementos nos requisitos. Ferramentas de automao adequadas so de fundamental importncia para o gerenciamento dos requisitos, pois a dificuldade est no grande volume de informao gerado.
Atividades e Orientaes de Estudos

Para melhor assimilar o contedo deste captulo sugerimos algumas atividades de fixao. Como o assunto simples e bem objetivo, teremos basicamente os seguintes tipos de atividades para esse captulo: 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.
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
1. Cite exemplos de requisitos funcionais e no funcionais para um sistema de controle
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.
Aprenda Praticando - Exerccio Proposto 1.1

Tomando com base o que foi explicado no captulo, responda as questes abaixo, justificando suas respostas quando apropriado. 1. Explique qual a importncia da elicitao de requisitos para a Engenharia de software. 2. Explique cada uma das fases do processo de ER. 3. Indique os possveis stakeholders de um sistema de catalogao bibliotecria. 4. D exemplos, pelo menos 5, de requisitos funcionais para os 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. 5. D exemplos, pelo menos 3, de requisitos no funcionais para os seguintes sistemas: a) Um sistema de aprendizagem virtual como o que voc usa para acessar esse curso. b) Um jogo jogado em rede. c) Um sistema de transaes bancrias. 6. Sugira como reescrever os seguintes requisitos numa forma que possa ser quantificada: a) O sistema bibliotecrio deve ser fcil de usar;
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
gerir quando h uma grande nmero de requisitos.
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.
Aprenda Pesquisando - Pesquisa Proposta 1.1

A fim de aprofundar um pouco mais seu conhecimento sobre os conceitos e caractersticas bsicas do software, selecionamos alguns tpicos para pesquisa. 1) Em grupo de 4 alunos (2 no papel de desenvolvedor e 2 no papel de usurios) simular uma reunio para especificao de requisitos de um sistema de controle de biblioteca (use seus conhecimentos sobre o processo da biblioteca para fazer o papel de usurio). Ao termino da reunio, crie um documento com: nome do sistema; reas envolvidas; objetivos do sistema; restries; descrio funcional 2) De forma individual, elabore uma entrevista para um cargo especfico a) Defina qual esse cargo; b) Entreviste 3 pessoas; c) Identifique a melhor pessoa para o cargo. A entrevista deve ter tudo!!! Horrio, Data, Questes, Durao, Respostas, etc. Aps cada entrevista, monte um relatrio. Contendo itens da entrevista, anlise comportamental, etc. Anotar dificuldades. 3) Pesquise sobre dicas de como descrever requisitos de software. Tente buscar informaes de: forma gramatical recomendada, padres, organizao, tipos, etc. 4) Pesquise sobre ferramentas destinadas a gesto de requisitos. Quais so as principais funes dessas ferramentas? Com que outras ferramentas elas podem ser integradas? Quanto elas custam?
Aprenda Interagindo - Exerccio de Interao 1.1

Utilizando os fruns do curso, realize as atividades de interao propostas a seguir. Sugerimos que seja criado um frum especifico para o capitulo, dessa forma, torna-se fcil a indexao das discusses no curso para consulta e anlise posterior. 1) Adotando o frum do curso como meio de comunicao e expresso de ideias, comente sobre os seguintes tpicos: a) Discuta alguns dos problemas que ocorrem quando os requisitos devem ser levantados de trs ou quatro clientes diferentes.
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>.
Leio o artigo Os requisitos e o sucesso do seu projeto, de Jos Carlos Macoratti.
26
Disponvel em: <http://www.macoratti.net/ger_proj1.htm>
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
Captulo 2 Projeto de Software

...O crtico romano de arquitetura Vitruvius adiantou a noo de que edifcios bem projetados eram aqueles que exibiam firmeza, comodidade e prazer. O mesmo poderia ser dito de um bom software. Firmeza: um programa no deve ter quaisquer erros que inibam sua funo. Comodidade: um programa deve ser adequado s finalidades para as quais foi planejado. Prazer: a experincia de usar o programa deve ser agradvel. Temos a o inicio de uma teoria de projeto de software. Trecho retirado do Cap. 9 de Pressman (2006). Este captulo tem por objetivo apresentar os conceitos e princpios fundamentais que so aplicveis a todo o projeto de software. Ao final do capitulo voc conhecer: Em que momento realizado o projeto de software; Quem o responsvel pelo projeto de software; Qual a importncia das atividades de projeto; Quais os conceitos fundamentais envolvidos; Quais os modelos de projeto; Algumas tcnicas de projeto.
2.1 Projeto e Engenharia de Software

Outra subrea de conhecimento associada a ES o Projeto de Software. Essa rea responsvel por transformar os resultados da anlise e especificao de requisitos realizados pela Engenharia de Requisitos em um documento ou conjunto de documentos capazes de serem interpretados diretamente pelo desenvolvedor (ou programador). Nesse sentido, h muito o que falar e explicar sobre projeto de software, como no podemos abordar tudo nesse curso, pois o escopo introdutrio daremos uma viso geral sobre os principais aspectos relacionados a essa subrea. Na sua forma mais clssica, o primeiro resultado obtido no projeto uma viso da
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
2.1.1 Processo de projeto

O processo de projeto pode ser descrito como o processo de escolha da representao de uma soluo a partir de vrias alternativas, dadas as restries envolvidas na especificao do software. Esse processo, ilustrado na Figura 2.1, pode ser dividido em duas fases: diversificao e convergncia.
Figura 2.1 Processo de projeto.
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.1.2 Caractersticas desejveis de um projeto de software

J sabemos que a obteno de um software de boa qualidade est relacionada ao sucesso de cada uma das etapas do seu desenvolvimento. No que diz respeito etapa de projeto, possvel detectar algumas das caractersticas desejveis: Deve apresentar uma organizao hierrquica, definida de modo a utilizar racionalmente todos os elementos de software; Deve se basear em princpios de modularidade, ou seja, propor um particionamento do software em elementos que implementem funes ou subfunes do software; Deve conduzir a uma definio em mdulos com alto grau de independncia, como forma de facilitar as tarefas de manuteno ao longo da vida do software; Deve ser fiel especificao dos requisitos definida na etapa anterior. Um projeto de software bem feito resolve problemas como: Produz uma arquitetura robusta, estvel e flexvel, que indispensvel para que o produto tenha alta qualidade e vida longa; Produz interfaces de usurios que tornem o produto fcil de aprender e de usar de maneira produtiva; Serve de base para o planejamento e projeto de testes de aceitao do produto; Escolhe as solues tecnolgicas mais adequadas para satisfazer os requisitos de forma rpida, barata e confivel; Divide adequadamente o produto em componentes que possam ser agrupados em um nmero satisfatrio de liberaes, permitindo a avaliao precoce por parte dos usurios; Divide adequadamente o produto em componentes cuja implementao possa ser dividida eficazmente entre os membros de uma equipe de desenvolvedores, diminuindo os prazos de implementao.
2.2 Princpios e tcnicas do projeto de software

Nas descries dos modelos de projeto de software, h um conjunto de princpios fundamentais que precisam ser observados independentemente da tcnica adotada na especificao desses modelos. Esses princpios so apresentados brevemente a seguir.
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.
2.2.3 Modularidade ou decomposio

O conceito de modularidade tem sido utilizado j h bastante tempo, como forma de obteno de um software que apresente algumas caractersticas interessantes como a facilidade de manuteno. Este conceito apareceu como uma soluo aos antigos softwares monolticos, os quais representavam grandes dificuldades de entendimento e, consequentemente para qualquer atividade de manuteno. A utilizao do conceito de modularidade oferece resultados a curto prazo, uma vez que, ao dividir-se um grande problema em problemas menores, as solues so encontradas com esforo relativamente menor. Isto significa que, quanto maior o nmero de mdulos definidos num software, menor ser o esforo necessrio para desenvolv-lo, uma vez que o esforo de desenvolvimento de cada mdulo ser menor. Por outro lado, quanto maior o nmero de mdulos, maior ser o esforo no desenvolvimento das interfaces, o que permite concluir que esta regra deve ser utilizada com moderao. Finalmente, importante distinguir o conceito de modularidade de projeto com o de modularidade de implementao. Nada impede que um software seja projetado sob a tica da modularidade e que sua implementao seja monoltica. Em alguns casos, como forma de evitar desperdcio de tempo de processamento e de memria em chamadas de procedimentos (salvamento e recuperao de contexto), impe-se o desenvolvimento de um programa sem a utilizao de funes e procedimentos. Ainda assim, uma vez que o projeto seguiu uma filosofia de modularidade, o software dever apresentar alguns benefcios resultantes da adoo deste princpio.
2.2.4 Ocultao de informao

O princpio da ocultao de informaes prope um caminho para decompor sistematicamente um problema de modo a obter, de modo eficiente, os diferentes mdulos do software a construir. Segundo este princpio, os mdulos devem ser decompostos de modo que as informaes (os procedimentos e dados) contidas em cada mdulo sejam inacessveis aos mdulos que no tenham necessidade destas informaes. Ao realizar a decomposio segundo este princpio, o projetista proporciona um grau relativamente alto de
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.
2.2.5 Diviso e conquista

Diviso e conquista uma tcnica para resoluo de problemas que consiste em decompor um problema em subproblemas menores e independentes a fim de resolv-los separadamente, para que, posteriormente, as solues sejam combinadas e formem a soluo do problema inicialmente proposto. provvel que voc j tenha ouvido e usado essa tcnica para desenvolver algum algoritmo. A estratgia baseada na ideia de que atacar um problema complexo por diversas frentes mais simples e factvel de resoluo do que tentar resolv-lo completamente de uma s vez. A tcnica de diviso e conquista possui trs etapas bem definidas: Diviso: dividir o problema original em subproblemas menores; Conquista: resolver cada um dos subproblemas gerados na fase de diviso; Combinao: combinar as solues de cada subproblema, compondo a soluo para o problema inicial.
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.
2.2.6 Acoplamento e coeso

Acoplamento e coeso so princpios usados para medir se mdulos de um design foram bem divididos. Acoplamento a medida de interdependncia entre mdulos de software. Ou seja, quanto mais dependente um mdulo A da implementao do mdulo B, maior o acoplamento entre os mdulos A e B. Alto acoplamento implica que (1) os mdulos envolvidos sero mais difceis de entender, uma vez que precisam ser entendidos em conjunto; (2) os mdulos envolvidos sero mais difceis de modificar, uma vez que as mudanas impactaro mais de um mdulo; e (3) os mdulos envolvidos sero mais difceis de manter, uma vez que um problema num mdulo se espalhar pelos mdulos com quem est altamente acoplados. Por outro lado, coeso uma medida intramdulo. Ela a medida da relao entre
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.
2.3 Conceitos fundamentais do projeto de software

Tambm importante deixar claro alguns conceitos fundamentais ao projeto. So eles: arquitetura de software; hierarquia de controle; estrutura de dados e procedimentos.
2.3.1 A arquitetura de software

O conceito de arquitetura de software est ligado aos dois principais aspectos do funcionamento de um software: a estrutura hierrquica de seus componentes (ou mdulos) e as estruturas de dados. A arquitetura de software resulta do desenvolvimento de atividades de particionamento de um problema, encaminhadas desde a etapa de anlise de requisitos. Naquela etapa, dado o pontap inicial para a definio das estruturas de dados e dos componentes de software. A soluo encaminhada ao longo do projeto, atravs da definio de um ou mais elementos de software que solucionaro uma parte do problema global. importante lembrar que no existe tcnica de projeto que garanta a unicidade de soluo a um dado problema. Diferentes solues em termos de arquitetura podem ser derivadas a partir de um mesmo conjunto de requisitos de software. A grande dificuldade concentra-se em definir qual a melhor opo em termos de soluo.
2.3.2 Hierarquia de controle

A hierarquia de controle nada mais do que a representao, usualmente sob a forma hierarquizada, da estrutura do software no que diz respeito aos seus componentes. O
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.
Figura 2.2 - Representao da hierarquia de controle.
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.
2.3.3 A estrutura dos dados

A estrutura dos dados representa os relacionamentos lgicos entre os diferentes elementos de dados individuais. medida que o projeto se aproxima da implementao, esta representao assume fundamental importncia, j que a estrutura da informao vai exercer um impacto significativo no projeto procedimental final. A estrutura dos dados define a forma como esto organizados, os mtodos de acesso, o grau de associatividade e as alternativas de processamento das informaes. Apesar de que a forma de organizar os elementos de dados e a complexidade de cada estrutura dependam do tipo de aplicao a desenvolver e da criatividade do projetista, existe um nmero limitado de componentes clssicos que funcionam como blocos de
35
construo (building-blocks) de estruturas mais complexas.
2.3.4 Procedimentos de software

Os procedimentos de software tm por objetivo expressar em detalhes a operao de cada componente de software (mdulo) individualmente. Os aspectos a serem expressos nos procedimentos de software so o processamento da informao, o sequenciamento de eventos, os pontos de deciso, as operaes repetitivas e, eventualmente (se houver necessidade), algumas estruturas de dados.
Figura 2.3 - Alguns construtores clssicos de estruturas de dados.
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.
2.4 Modelos de projeto

Olhando para os diversos aspectos apresentados na seo anterior, pode-se verificar que, de fato, a etapa de projeto de software caracterizada por um conjunto de projetos, que desenrolam-se paralelamente. Nos itens abaixo, sero discutidos estes diferentes projetos.
2.4.1 O projeto dos dados

medida que a etapa de projeto evolui, as estruturas de dados vo assumindo um papel mais importante nesta atividade, uma vez que estas vo definir a complexidade
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 O projeto arquitetural

Como j mencionado neste captulo, o projeto arquitetural visa obteno de uma estrutura modular de programa, dotada de uma representao dos relacionamentos de controle entre os mdulos. Ainda, esta atividade permite efetuar a fuso dos aspectos funcionais com os aspectos informacionais, a partir da definio de interfaces que iro definir o fluxo de dados atravs do programa. Uma questo importante no que diz respeito ao projeto arquitetural que ele deve ser encaminhado prioritariamente a outros projetos. importante, antes que outras decises possam ser tomadas, que se tenha uma viso global da arquitetura do software. O que estiver definido a nvel do projeto da arquitetura do software vai ter, sem dvida, grande impacto nas definies relativas aos demais projetos.
2.4.2.1 Linguagem de descrio de arquitetura

As linguagens de descrio de arquitetura (LDAs) so usadas para descrever a arquitetura de software. Vrias diferentes LDAs foram desenvolvidas por diferentes organizaes, incluindo Wright (desenvolvido por Carnegie Mellon), Acme (desenvolvido por Carnegie Mellon), xADL (desenvolvido por UCI), Darwin (desenvolvido por Imperial College London), DAOP-ADL (desenvolvido pela University of Mlaga). Elementos comuns de uma LDA so componente, conexo e configurao.
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.
2.4.3 O projeto procedimental

O projeto procedimental encaminhado a partir da definio da estrutura do software. Devido riqueza de detalhes que pode caracterizar o projeto procedimental, a adoo de notaes adequadas ao projeto uma necessidade, como forma de evitar a indesejvel ambiguidade que poderia ser resultante da utilizao, por exemplo, da linguagem natural.
2.4.3.1 A programao estruturada

A programao estruturada, introduzida no final dos anos 60, foi uma interessante forma de se encaminhar projetos e implementaes de software oferecendo facilidade de programao e de entendimento. A ideia por trs da programao estruturada a utilizao de um conjunto limitado de construes lgicas simples a partir das quais qualquer programa poderia ser construdo. Cada construo apresentava um comportamento lgico previsvel, iniciando no topo e finalizando na base, o que propiciava ao leitor um melhor acompanhamento do fluxo procedimental. Independente da linguagem utilizada para a implementao, ela era composta basicamente de trs classes de construes: as sequncias, as condies e as repeties. O uso de um nmero limitado de construes simples (as quais podem ser combinadas das mais variadas formas) permite obter, sem dvida, programas mais simples. Um programador que domine efetivamente as construes bsicas da programao
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.
2.4.3.3 O uso de notaes grficas

Outra contribuio importante s atividades de projeto pode ser adoo de notaes grficas para representar os procedimentos a serem implementados. O fluxograma uma conhecida tcnica para a representao do fluxo de controle de programas, particularmente, os programas sequenciais. Os fluxogramas estruturados so aqueles baseados na existncia de um conjunto limitado de fluxogramas bsicos que, combinados, compem uma representao de comportamento de um elemento de software. O resultado obtido uma representao grfica de comportamento que pode, eventualmente, ser representada por um pseudocdigo. Exemplos de fluxogramas bsicos para a composio de fluxogramas mais complexos so apresentados na Figura 2.4. Uma tcnica grfica tambm definida para a representao de comportamento de componentes de um software o diagrama de Nassi-Schneiderman. Esta tcnica baseada na representao atravs de caixas, das estruturas de controle clssicas. De forma similar aos fluxogramas estruturados, os diagramas de NassiSchneiderman so baseados na existncia de blocos bsicos representando estruturas elementares de controle que sero combinados de modo a compor a representao total do software (ou do componente de software) projetado.
39
Figura 2.4 - Exemplos de blocos bsicos para fluxogramas estruturados.
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.
Figura 2.5 - Exemplos de blocos bsicos dos diagramas de Nassi-Schneiderman.

Para melhor assimilar o contedo deste captulo sugerimos algumas atividades de fixao exatamente como o capitulo anterior. Como o assunto simples e bem objetivo, teremos basicamente os mesmos tipos de atividades definidos para o captulo anterior, so elas:
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.
Aprenda Praticando - Exerccios Proposto 2.1

Tomando com base o que foi explicado no captulo, responda as questes abaixo, justificando suas respostas quando apropriado. 1) Quais os benefcios de se projetar sistemas? 2) Duas fases importantes do projeto de software so as fases de Divergncia e Convergncia. Descreva o que feito em cada fase. 3) Voc projeta software quando escreve um programa? O que faz o projeto de software diferente da codificao? (Pressman, 2006). 4) Examine o conjunto de tarefas apresentado para o projeto. Onde a qualidade avaliada nesse conjunto de tarefas? (Pressman, 2006) 5) Quais os princpios seguidos pelo projeto de software? Explique, pelo menos 2 deles. 6) Descreva o que arquitetura de software com suas prprias palavras? (Pressman, 2006) 7) Por que o projeto de software de alto nvel se preocupa tanto na definio das interfaces entre os componentes ou mdulos do software?
Aprenda Pesquisando - Pesquisa Proposto 2.1

A fim de aprofundar um pouco mais seu conhecimento sobre a Engenharia de Software e seus paradigmas, selecionamos alguns tpicos para pesquisa. 1) Pesquise sobre padres de projeto de software. Como eles so utilizados no projeto de software? Selecione um, descreva-o e fornea exemplos prticos de sua utilizao. 2) Pesquise sobre ferramentas case de auxilio a modelagem do projeto de
41
software. Descreva que funcionalidades ela apresentam e a que paradigma de desenvolvimento de software elas correspondem.

Utilizando os fruns do curso, realize as atividades de interao propostas a seguir. Sugerimos que seja criado um frum especifico para o capitulo, dessa forma, torna-se fcil a indexao das discusses no curso para consulta e anlise posterior. bom sempre lembrar que ser preciso voc acessar o ambiente para realizar as atividades de interao. No esquea: voc tambm ser avaliado pelas participaes significativas nos fruns de discusso apresentados no ambiente. 1) Tendo como base o texto a seguir, comente sobre o papel do projeto de software para alcanar o objetivo do texto. Atualmente, h no mundo quase 1(um) trilho de linhas de cdigo escritas em pouco mais de 500 (quinhentas) linguagens. Adicionalmente, tem-se uma variedade de plataformas e utilitrios de apoio que evoluem constantemente. Concomitante a isso, a presso do mercado para reduzir o tempo de desenvolvimento dos produtos, exige dos desenvolvedores a habilidade de construir sistemas com qualidade e requer dos gerentes de projeto a capacidade de gesto que visa garantir tanto a entrega do produto quanto a satisfao do cliente. Nesse sentido, tem havido esforos para reutilizar artefatos desenvolvidos em projetos anteriores.
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
Captulo 3 Verificao, validao e

teste do software (VVT)
A fase de testes ocupa, normalmente, 40% do tempo planejado para um projeto e um erro descoberto tardiamente em um sistema provoca um acrscimo de 60% nos custos do projeto. Isso acontece porque nenhum engenheiro ou analista, por mais experiente que seja, est imune a falhas de codificao e projeto. Estes so alguns dos motivos que tm feito com que a atividade de teste de software tenha se tornado um dos itens mais estudados no contexto de aprimoramento da qualidade de software. Apesar de parecer simples primeira vista, a atividade de teste exige um bom planejamento e controle durante a execuo para ser bem sucedida. Conhecer os aspectos da atividade de testes como as limitaes, objetivos, formas de criao de massa de testes e de aplicao de tcnicas de teste de acordo com o momento do projeto, facilita o trabalho de planejamento e controle. E nesta atividade o melhor investir ao longo de todo o processo de forma equilibrada para evitar a necessidade de um esforo muito grande e menos efetivo ao final do desenvolvimento. No captulo 3 desta unidade, abordaremos um tpico muito importante para o desenvolvimento de software: a verificao, validao e testes de software. Esse assunto muito extenso, tanto que a diversos cursos de especializaes so destinados a formao de pessoal especializado apenas nessa rea de conhecimento, alm disso, h inmeros cursos tcnicos disponveis em muitas Instituies. Assim, no nossa ambio aqui explorar extensamente essa rea de conhecimento, precisaramos de um curso especfico apenas para isso. Abordaremos apenas alguns dos principais conceitos envolvidos, mas deixamos a quem interessar referncias para aprofundar o conhecimento sobre o assunto. Aqui conheceremos um pouco sobre: Diferenas entre verificao e validao; Algumas tcnicas de verificao;
44
Fundamentos dos testes de software; Classificao dos testes de software; Algumas atividades do processo de testes.
3.1 Introduo s atividades de VVT

Recapitulando um pouco o que vimos at aqui: primeiro ns executamos as atividades de levantamento e especificao dos requisitos do software atravs da Engenharia de Requisitos, depois passamos a desenvolver os modelos de projeto, e logo em seguida pelo ciclo genrico de produo do software, passamos para a construo ou codificao do software. Mais as atividades no param por a. Infelizmente, impossvel garantir que o software produzido esteja livre de erros e falhas. E uma das formas de minimizar esses erros, executando uma srie de atividades de verificao, validao e testes de software que acontecem em diversos momentos durante o ciclo de produo. Isso se repete at que todo o produto de software esteja totalmente desenvolvido, testado e seja liberado para uso. Essas atividades representam outra subrea de conhecimento da ES. Vamos entender as diferenas entre os termos verificao, validao, e testes.
Voc Sabia que...

Um estudo realizado pela IBM (1981) mostra que enquanto um erro encontrado e corrigido durante a fase de projeto custa uma unidade monetria, se o mesmo for encontrado durante a atividade de teste do cdigo, custar 15 unidades. Aps o lanamento do produto no mercado, a correo do mesmo erro custar entre 60 e 100 unidades monetrias. Os resultados da pesquisa levam concluso de que, quanto antes um erro for detectado, melhor, pois o custo para reparo menor.
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
comportamentos esto associados aos aspectos de validao do produto.
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.
3.1.1 Objetivos das atividades de VVT

O objetivo das atividades de VVT pode ser entendido da seguinte forma: No incio de cada fase verificar se esta etapa do projeto reflete exatamente os requisitos e definies da fase imediatamente anterior, para com isso garantir que o produto encomendado e o gerado pela atividade de desenvolvimento do software sejam os mesmos, atravs dos diferentes nveis de refinamento do projeto, por exemplo, o modelo de projeto deve estar consistente com os requisitos do software; Verificar se no existem erros de lgica no projeto e cdigo, no fluxo de dados, no entendimento de requisitos, de codificao, tipogrficos ou de interface em todas as fases do projeto; Identificar e interferir na presena do erro, iniciando-se a depurao, sendo que quanto antes for descoberta a falha, menos custoso ser para adequ-la; Ter em mente que, uma vez que errar humano e atividade de desenvolvimento de software um exerccio bastante complexo, os erros existem e devem ser descobertos. Portanto, o sucesso nas atividades de VVT consiste em descobrir os erros e corrigi-los o mais cedo possvel.
46
3.2 Algumas tcnicas de verificao

Uma das tcnicas de verificao mais adotada a reviso tcnica. Ela pode ser aplicada em qualquer artefato gerado e a qualquer tempo durante o ciclo de desenvolvimento do software, desde o cdigo a documentos de requisitos ou arquitetura, por exemplo. Alis, a reviso tcnica pode ser utilizada em qualquer artefato, por exemplo, voc com seus colegas poderiam se reunir para revisar tecnicamente um trabalho de testes realizado durante o curso. No contexto da ES, acontece que durante o planejamento do software j se defina em que momentos as revises precisaro ser realizadas, esses momentos so chamados de ponto de verificao (do ingls, checkpoints). No Quadro 3.1 ilustramos alguns artefatos que podem ser verificados e o objetivo dessa verificao para o processo de desenvolvimento de software. Por exemplo, o documento de requisito deve ser revisado buscando a aprovao dos requisitos aprovados e tambm para definir uma verso de base para a modelagem do projeto arquitetural do software. A definio desses pontos depende na prtica da natureza do projeto e de suas respectivas restries. Por exemplo, um software embarcado exige maior qualidade no software, pois erros encontrados aps a liberao custaro muito caro ao fabricante, exigiria a troca ou recall de vrios equipamentos j liberados no mercado, fora possveis indenizaes por danos ou algo assim, dessa forma, o processo de desenvolvimento adotado para esses softwares so mais rigorosos no sentido de garantir uma alta qualidade do software - as verificaes e validaes so atividades constantes e realizadas em diversos momentos. importante frisar que isso acarreta em um tempo maior de desenvolvimento e tambm em custos maiores, e isso nem sempre possvel para muitos projetos. Essa rigorosidade j no to necessria para um software como o de controle de uma biblioteca, por exemplo, isso no quer dizer que a qualidade no seja importante nesse caso, mas que ela pode ser adquirida em um nvel razovel que no aumente tanto os custos finais do projeto.
Quadro 3.1 Exemplos de artefatos revisados e os objetivos dessa reviso Artefato revisado Requisito do software Plano de teste Projeto preliminar Projeto detalhado Reviso de mdulos Objetivo da reviso Aprovar a especificao de requisitos e iniciar projeto preliminar baseado em requisitos estveis Aprovar a estratgia de teste Estabelecer uma linha base para o projeto e determinar uma abordagem bsica para o projeto e teste do software Aprovar projeto detalhado; autorizar o incio da codificao e teste Aprovar a finalizao da implementao e teste das unidades; liberar para demais fases de teste
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.
3.3 Testes de software

Uma vez conversado um pouco sobre verificao de software, passemos aos testes. A tarefa de efetuar testes em software foi considerada secundria por muito tempo. Geralmente era vista como um castigo pelo engenheiro de software, ou como uma tarefa onde no se deveria gastar muito tempo e investimentos. O tema sempre esteve em segundo plano, e, at alguns anos atrs no se encontrava muita literatura sobre o assunto. Agora esse cenrio completamente diferente. Com a globalizao e o acirramento da competio, passou a ocorrer uma grande
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.
Voc Sabia que...

No contexto da ES, o caso de teste um conjunto de condies usadas para teste de software. Ele pode ser elaborado para identificar defeitos na estrutura interna do software, atravs de situaes que exercitem adequadamente todas as estruturas utilizadas na codificao; ou ainda, garantir que os requisitos do software que foi construdo sejam plenamente atendidos. Fonte: Wikipedia (caso de teste).
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.
3.3.1 Alguns conceitos bsicos

Seguem alguns conceitos importantes envolvidos com o processo de teste. Falta: a falta caracteriza-se pela ausncia de requisitos especificados para o sistema. Defeito: o defeito caracteriza-se pelo no funcionamento ou funcionamento incorreto de algum dos requisitos especificados para o sistema. Depurao: Encontrar a causa do erro detectado no teste, projetar e implementar as modificaes no programa para a correo do respectivo.
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.
3.3.2 Princpios dos testes

Adaptando a citao de Glen Myers (1979), pode-se dizer que a atividade de teste de software o processo de revisar especificaes, projetos e programas com a inteno de descobrir erros. Alguns dos itens que so comuns a todos autores e pesquisadores do
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.
3.4 Classificao dos testes

Segundo o SWEBOK (2004), os testes so executados segundo diferente nveis
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.
3.4.1 Testes de unidade

O teste de unidade objetiva a verificao de erros existentes nas unidades de projeto do mesmo, a qual daremos o nome de mdulo, mas poderia ser uma classe, em projetos orientados a objetos. Nesta modalidade de teste, importante utilizar as informaes contidas no documento de projeto detalhado do software, as quais serviro de guia para sua aplicao. O teste de unidade , de certa forma, uma tcnica de teste de caixa branca, podendo ser realizado em paralelo sobre diferentes mdulos.
3.4.2 Testes de integrao

O teste de integrao, como o nome indica, objetiva a busca de erros surgidos quando da integrao das diferentes unidades componentes do software. importante lembrar que, o fato de se ter analisado os mdulos do software de forma exaustiva (atravs de procedimentos de teste de unidade), no h nenhuma garantia de que estes, uma vez colocados em conjunto para funcionar, no apresentaro anomalias de comportamento. Uma das maiores causas de erros encontrados durante o teste de integrao so os chamados erros de interface, devido, principalmente, s incompatibilidades de interface entre mdulos que devero trabalhar de forma cooperativa.
3.4.3 Testes de sistemas

Neste tipo de teste, so verificados os aspectos de funcionamento do software, integrado aos demais elementos do sistema, como o hardware e outros elementos. Dependendo do destino do software, somente neste momento do teste em que alguns peris de funcionamento do software podem ser efetivamente testados (particularmente, aqueles aspectos do funcionamento que dependem da interao dos demais elementos do sistema).
3.4.4 Testes alfa e beta

So os testes de aceitao, feitos pelo usurio, que dificilmente opera o sistema da forma prevista, e visam descobrir erros cumulativos que poderiam deteriorar o sistema no decorrer do tempo. O teste alfa executado por um cliente nas instalaes do desenvolvedor, sendo acompanhado pelo desenvolvedor, que registra os problemas encontrados no uso. O ambiente controlado. J o teste beta realizado em uma ou mais instalaes do cliente pelo usurio final do software. Geralmente o desenvolvedor no est presente. Assim, o teste beta uma aplicao real do software, sem que haja controle por parte do desenvolvedor. Os problemas so registrados pelo usurio e repassados regularmente ao desenvolvedor, que corrige o software antes de lanar o produto para venda.
53
3.4.5 Testes de validao

O teste de validao pode ser considerado bem sucedido quando o software funciona da maneira esperada pelo cliente. Ou seja, verifica-se se o produto certo foi construdo, seguindo a especificao de requisitos do software. A validao do software, na fase de testes, realizada por meio de uma srie de testes de caixa preta que demonstram a conformidade com os requisitos.
3.4.6 Teste de segurana

O teste de segurana tenta verificar se todos os mecanismos de proteo embutidos em um sistema o protegero de acessos indevidos. Todas as formas de ataque devem ser simuladas. A finalidade dificultar o acesso indevido de forma que seja mais interessante e barato obter a informao de forma correta e legal.
3.4.7 Testes de estresse

O teste de estresse feito para confrontar o sistema com situaes anormais. O teste de estresse executa o sistema de forma que exige recursos em quantidade, frequncia ou volume anormais.
3.4.8 Teste de desempenho

O teste de desempenho idealizado para testar o desempenho do software quando executado dentro do contexto de um sistema integrado. Algumas vezes os testes de desempenho so combinados com os de estresse e podem ser executados durante todo o processo de desenvolvimento.
3.4.9 Testes funcionais

Uma vez que testes exaustivos no so viveis, caractersticas do domnio de entrada so examinadas para que se tente descobrir formas de derivar um conjunto de dados de teste representativo que consiga exercitar completamente a estrutura do sistema. Os dados de teste precisam ser derivados de uma anlise dos requisitos funcionais e incluir elementos representativos de todas as variveis do domnio. Este conjunto deve incluir tanto dados de entrada vlidos quanto invlidos. Geralmente, os dados no conjunto de dados de teste podem ser classificados em trs classes: de fronteira, no de fronteira e especiais. Exemplificando: Se X for um nmero e se tivermos X tal que, a < X < b, ento X deve ser testados para os valores a + 1 e b 1 da classe vlida, para os valores a e b da classe invlida e para valores especiais tais como zero, vazio, ou caracteres alfabticos. So considerados mtodos de testes funcionais ou de caixa preta: o particionamento de equivalncia, a anlise de valor limite, a tcnica de grafo de causa-efeito e os testes de comparao.
3.5 Processo de testes

O processo de testes de software representa uma estruturao de etapas, atividades, artefatos, papis e responsabilidades que buscam a padronizao dos trabalhos
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.
Figura 3.3 Modelo de processo de teste em V.
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
Figura 3.4 Entrada para o projeto de casos de testes.
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.
Figura 3.5 Processo de testes.
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
Figura 3.6 Processo de teste e processo de desenvolvimento.

Como no capitulo anterior sugerimos algumas atividades de fixao para assimilar melhor o contedo deste captulo. Como o assunto simples e bem objetivo, exatamente como nos capitulos anteriores, teremos basicamente os mesmos tipos de atividades: 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
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.
Aprenda Praticando - Exerccio Proposto 3.1

Tomando com base o que foi explicado no captulo, responda as questes abaixo, justificando suas respostas quando apropriado. 1. Indique V para Verdadeiro e F para Falso: a. ( ) Os padres de software so importantes para a garantia de qualidade, uma vez que representam uma identificao da melhor prtica. b. ( ) O objetivo dos testes apontar problemas no software.
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
Aprenda Pesquisando - Pesquisa Prposta 3.1

A fim de aprofundar um pouco mais seu conhecimento sobre ferramentas case aplicada aos testes, selecionamos alguns tpicos para pesquisa. 1) Pesquise sobre ferramentas que auxiliam no processo de teste de software. Que funcionalidades mais comuns que elas trazem? Elas so gratuitas? Qual o custo de adquiri-las? Qual a vantagem em adotar uma delas.

Utilizando os fruns do curso, realize as atividades de interao propostas a seguir. Sugerimos que seja criado um frum especifico para o capitulo, dessa forma, torna-se fcil a indexao das discusses no curso para consulta e anlise posterior. bom sempre lembrar que ser preciso voc acessar o ambiente para realizar as atividades de interao. No esquea: voc tambm ser avaliado pelas participaes significativas nos fruns de discusso apresentados no ambiente. 1) Tendo como base a afirmao abaixo discuta no frum as razes que tornam essa afirmao verdadeira no contexto da Engenharia de Software. 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. 2) A afirmao abaixo verdadeira ou falsa? Por que? Embora exista toda uma detalhada teoria sobre Testes de Software, empresas como Microsoft, Yahoo!Google lanam interminveis verses beta e assim se livram do nus de testar produtos em profundidade e responder por falhas.
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/>
Apresentao sobre testes de software. Disponvel em: <http://www.slideshare.net/ FabricioFFC/introduo-ao-teste-de-software-uma-abordagem-prtica>
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)
At l e bons estudos! Danielle R. D. da Silva Autora
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

Fes Vol Ii

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Fes Vol Ii

Transféré par

Droits d'auteur :

Formats disponibles

UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO (UFRPE)

COORDENAO GERAL DE EDUCAO A DISTNCIA (EAD/UFRPE)

Fundamentos da Engenharia de Software

Danielle Rousy Dias da Silva

Bons estudos! Danielle R. D. da Silva Autora

Fundamentos da Engenharia de Software

Mdulo 2 reas de Conhecimento Base da Engenharia de Software

Contedo Programtico do Mdulo 2:

Fundamentos da Engenharia de Software

Captulo 1 Engenharia de Requisitos

1.1 Requisitos de Software

Fundamentos da Engenharia de Software

Figura 1.1 Tipos de requisitos e seus interessados.

Fundamentos da Engenharia de Software

1.1.1 Requisitos Funcionais

1.1.2 Requisitos No-funcionais

Fundamentos da Engenharia de Software

O tempo de desenvolvimento no deve ultrapassar seis meses.

Fundamentos da Engenharia de Software

Completa Correta Compreensvel Consistente Concisa Confivel

1.2 Engenharia de Requisitos (ER) e Engenharia de Software (ES)

Voc sabia que...

Fundamentos da Engenharia de Software

Figura 1.2 Engenharia de requisitos (ER).

Fundamentos da Engenharia de Software

Figura 1.3 Entrada e sada do processo de ER.

1.3 Ponto de partida para um processo de ER

Fundamentos da Engenharia de Software

1.4 Processo Genrico da ER

Fundamentos da Engenharia de Software

Figura 1.4 Fases e atividades do processo de ER.

1.4.1 Elicitao de Requisitos

Voc sabia que...

Fundamentos da Engenharia de Software

Fundamentos da Engenharia de Software

1.4.1.1 Algumas tcnicas de elicitao de requisitos

Fundamentos da Engenharia de Software

Fundamentos da Engenharia de Software

Voc sabia que...

Fundamentos da Engenharia de Software

1.4.2 Anlise e negociao de requisitos

1.4.3 Documentao dos requisitos

Fundamentos da Engenharia de Software

Fundamentos da Engenharia de Software

Figura 1.6 Esboco dos SRS segundo diversos modelos.

1.4.4 Validao e verificao de requisitos

Fundamentos da Engenharia de Software

1.4.5. Gerenciamento de requisitos

Atividades e Orientaes de Estudos

1. Cite exemplos de requisitos funcionais e no funcionais para um sistema de controle

Fundamentos da Engenharia de Software

Aprenda Praticando - Exerccio Proposto 1.1

Fundamentos da Engenharia de Software

Fundamentos da Engenharia de Software

gerir quando h uma grande nmero de requisitos.

Aprenda Pesquisando - Pesquisa Proposta 1.1

Aprenda Interagindo - Exerccio de Interao 1.1

Fundamentos da Engenharia de Software

Leio o artigo Os requisitos e o sucesso do seu projeto, de Jos Carlos Macoratti.

Fundamentos da Engenharia de Software

Disponvel em: <http://www.macoratti.net/ger_proj1.htm>

Fundamentos da Engenharia de Software

Captulo 2 Projeto de Software