Gerência de Requisitos

Tamanho: px
Começar a partir da página:

Download "Gerência de Requisitos"

Transcrição

1 Gerência de Requisitos Miriam Sayão 1 e Karin Koogan Breitman 2 Abstract Requirements management is a fundamental activity to software development process. Requirements constitute the basis for system design, for implementation, for tests cases and for software validation. Requirements management process is related to control the whole development process using the requirements baseline as main reference. This process aims to maintain plans, artifacts and development activities in consistency with requirements defined for the software. This course discusses several aspects related to requirements changes control, to requirements version control, to traceability and to quality in requirements. Resumo Gerenciamento de Requisitos é uma das atividades fundamentais ao processo de desenvolvimento de software. Requisitos constituem a base para a definição da arquitetura do sistema, para a implementação propriamente dita, para geração dos casos de testes e para validação do sistema junto ao usuário. Gerenciamento de requisitos está relacionado ao processo de controlar todo o processo de desenvolvimento tendo como referência a baseline de requisitos. Este processo visa manter planos, artefatos e atividades de desenvolvimento consistentes com o conjunto de requisitos definidos para o software. Neste curso abordaremos aspectos relacionados ao controle de mudanças em requisitos, ao gerenciamento da configuração, à rastreabilidade e à qualidade em requisitos. 1 Faculdade de Informática da PUC-RS e DI/PUC-Rio; 2 Departamento de Informática da/puc-rio;

2 1.1. Conceitos Básicos Nesta seção apresentamos os conceitos básicos relativos à disciplina de Engenharia de Requisitos e aos processos de Produção e Gerência de Requisitos. Iniciamos nossa discussão com a definição do termo Requisito. Segundo Dorfman e Thayer um requisito é definido como [Dorfman90]: Uma capacidade de software que o usuário necessita de modo a resolver um problema ou alcançar um objetivo Uma capacidade de software que deve ser disponibilizada por um sistema ou componente de sistema de modo a satisfazer um contrato, padrão, especificação ou outra formalidade imposta. Segundo Ian Sommerville requisitos são definidos nas fases inciais de um projeto e servem como especificação do que deve ser implementado. São descrições de como o sistema deve se comportar, de uma propriedade ou atributo do sistema. Um requisito pode descrever: Uma facilidade encontrada no nível do usuário Uma propriedade geral do sistema Uma restrição do sistema Uma restrição ao desenvolvimento do sistema Uma discussão freqüente na literatura de Engenharia de requisitos é a distinção entre o QUE e COMO. Alguns autores pregam que os requisitos devem descrever apenas o que sistema deve fazer (QUE) não se atendo aos detalhes de implementação (COMO). Alan Davis aponta que em muitos casos esta distinção é quase impossível de ser feita, pois dependendo do nível de detalhe da análise, o QUE de um processo pode servir de COMO para o refinamento do mesmo [Davis93] Tipos de Requisitos De modo geral os requisitos de software são classificados em três categorias: Requisitos funcionais São requisitos diretamente ligados à funcionalidade do software, o que o sistema deve prover. Suzanne e James Robertson definem requisitos funcionais como "uma ação que o produto deve ser capaz de realizar" [Robertson05] Exemplo: O sistema deve emitir um recibo após cada transação de compra. Requisitos não funcionais São requisitos que expressam restrições que o software deve atender ou qualidades específicas que o software deve ter. Suzanne e James Robertson definem requisitos não funcionais como "uma qualidade que o produto deve possuir." [Robertson05] Exemplo: O tempo de impressão de qualquer documento não deve exceder 1 minuto.

3 Requisitos inversos São requisitos que definem estados e situações que nunca devem ocorrer. Exemplo: O sistema não pode deixar que a temperatura da caldeira ultrapasse 100 o C. Independente do tipo do requisito, um aspecto fundamental é distinguir bons requisitos daqueles que apresentam riscos potenciais. Como sabemos se os requisitos do sistema foram capturados corretamente, estão bem escritos, livres de ambiguidade e completos? Na seção 1.5 discutiremos estes tópicos ao abordar qualidade dos requisitos e da especificação Engenharia de Requisitos A Engenharia de Requisitos (ER) é uma sub-área da Engenharia de Software que estuda o processo de produção e gerência dos requisitos que o software deverá atender. Este processo tem início junto aos clientes durante a fase de elicitação ou levantamento dos requisitos e perpassa todas as fases do processo de desenvolvimento do software. O objetivo da ER é fornecer métodos, técnicas e ferramentas que forneçam suporte adequado às tarefas de produção (elicitação, modelagem e análise) e gerência dos requisitos do sistema. A Engenharia de Requisitos foi estabelecida como disciplina independente em 1993, quando da criação do IEEE International Symposyum on Requirements Engineering (RE 93). A área tem crescido desde então. Atualmente temos a conferência internacional de requisitos RE (IEEE International Requirements Conference), que além dos artigos apresentados engloba uma serie de workshops com temas relacionados a requisitos e o WER, Workshop Engenharia de Requisitos (WER), criado em 1998 para atender ao público ibero-americano, já que aceita trabalhos em português e espanhol. Os artigos do WER estão disponibilizados na rede, através do site O Requirements Engineering Journal, publicado pela Springer Verlag London, é o periódico internacional dedicado à área de Engenharia de Requisitos. Klaus Pohl define a Engenharia de Requisitos da seguinte forma [Pohl93]: Engenharia de Requisitos pode ser definida como o processo sistemático de desenvolvimento de requisitos através de um processo cooperativo de análise onde os resultados das observações são codificados em uma variedade de formatos e a acurácia das observações é constantemente verificada. Linda Macaulay discute a definição proposta por Pohl, que enfatiza as questões centrais da Engenharia de requisitos. Entre outras estão: Como este processo pode ser sistemático se tantos fatores são desconhecidos no início do processo de desenvolvimento de software?

4 Quantas interações serão necessárias para realmente verificar a acurácia das observações (esta questão está diretamente ligada ao processo de validação e verificação dos requisitos, ver seção 1.5 qualidade) Como sabemos que ja foram levantados requisitos suficientes? Os usuários devem ser incluídos no processo ou são meramente fontes de informação? Quantas e quais representações devem ser utilizadas na codificação dos requisitos? Quais padrões devem ser adotados e quais notações existentes podem ser adaptadatas para atender o processo de captura e codificação de requisitos? Qual o nível de precisão dos requisitos? Como sabemos que chegamos ao final do processo? Muitas destas perguntas ainda estão em aberto e estão sendo abordadas por pesquisadores de requisitos no mundo inteiro, o que contribui para um crescente interesse por parte de profissionais e pesquisadores em relação ao papel da Engenharia de Requisitos no processo de produção de software. Levantamentos recentes da comunidade européia bem como do Software Engineering Institute (SEI) nos Estados Unidos apontam para problemas relacionados à Engenharia de Requisitos como os mais importantes. Nos Estados Unidos a gerência de requisitos é vista como um dos principais problemas a serem superados para que as organizações cheguem ao nível 2 de maturidade segundo o modelo CMM (Capability Maturity Model) do SEI, sendo que o próprio SEI disponibilizou recentemente um pacote que ajuda a transferência de tecnologia em Engenharia de Requisitos para facilitar a certificação das empresas. No entanto ainda existe confusão entre os termos Engenharia e Gerência de Requisitos. A Engenharia de Requisitos, como mencionado acima, engloba os processos de produção e gerência de requisitos, como ilustrado na figura 1.1. Figura Engenharia de requisitos Produção de Requisitos

5 Segundo Ian Sommerville, um bom processo de produção de requisitos tem de levar em conta as seguintes etapas: elicitação, análise e negociação e validação [Sommerville97]. Este ponto de vista é compartilhado por Julio Cesar Sampaio do Prado Leite, pesquisador chefe da linha de Engenharia de Requisitos da PUC-Rio [Leite01a]. Para este pesquisador os processos essenciais à produção de requisitos são: elicitação, modelagem e análise (validação e verificação). Karl Wiegers inclui um quarto processo, especificação, que foca na documentação de informação relativa a rastreabilidade dos requisitos. Independente da organização dos processos, o fato é todos os enfoques levam em conta a captura (elicitação dos requisitos), registro (codificação, modelagem, utilizando-se algum tipo de representação persistente que garanta o acesso posterior aos requisitos e suas origens) e qualidade (validação e verificação de modo a garantir a acurácia das observações e informações levantadas durante o processo). Neste artigo vamos nos concentrar nos processo de gerência de requisitos Gerência de requisitos Durante o processo de desenvolvimento e operação de um sistema de software é natural o surgimento de novos requisitos e a necessidade de mudanças nos requisitos existentes. Este processo, também conhecido como evolução de sistemas, acontece como resultado de mudanças no meio ambiente onde o próprio sistema de software está inserido. Se o macrosistema muda os sistemas de software devem acompanhar esta mudança ou ficarão cada vez menos úteis [Lehman96]. O processo de mudança dos requisitos precisa ser controlado de modo a garantir a qualidade do sistema. O impacto destas mudanças precisa ser avaliado e compreendido de modo que sua implementação seja feita de maneira eficiente e a baixo custo. Este processo é conhecido como a gerência de requisitos, que pode ser definido da seguinte forma: Enfoque sistemático para a elicitação, organização e documentação dos requisitos do sistema e um processo que estabelece e mantém o acordo entre usuários e a equipe de projeto à medida que os requisitos se modificam [Leffingwell00]. Segundo Ian Sommerville, os principais aspectos ligados à gerência de requisitos são relacionados a: 1. Gerenciar as mudanças em requisitos existentes (pertencentes a especificação), 2. Gerenciar o relacionamento entre os requisitos, 3. Gerenciar as dependências entre o documento de requisitos e outros documentos produzidos durante o desenvolvimento de software. Para implementar uma gerência de requisitos eficaz é necessário, de antemão, definir um conjunto de políticas. É necessário definir um conjunto de objetivos para o processo de gerência. Estes objetivos devem ser claros e transmitidos para todos os integrantes da equipe. Todos os artefatos (documentos) produzidos durante o

6 desenvolvimento do software devem tornar a gerência dos requisitos visível e transparente. Estes documentos devem ser gerados levando-se em contas padrões externos e corporativos, de modo a assegurar consistência e uniformidade das informações. Políticas bem definidas para a gerência de configuração, controle de mudanças e rastreabilidade e garantia da qualidade precisam colocadas em prática de modo a viabilizar um processo dinâmico e eficaz de gerência de requisitos. Nas próximas seções vamos discutir os aspectos fundamentais de gerencia de requisitos. São eles: controle de mudanças, gerência da configuração, rastreabilidade e garantia da qualidade Controle de Mudanças Em um ambiente real de desenvolvimento de software mudanças são inevitáveis. Em muitos dos casos os requisitos do sistema mudam enquanto o sistema aida está sendo desenvolvido. As razões para mudanças são de vários tipos, entre outras: A complexidade dos sistemas impõe mudanças à medida que se adquire maior conhecimento sobre os mesmos, Requisitos errados ou mal definidos precisam ser corrigidos/ajustados ao longo do processo de desenvolvimento, Mudanças no ambiente: regras de negócios, leis, políticas internas, Desenvolvedores querem adicionar funcionalidades mais avançadas de modo a oferecer vantangem Tecnologia muda, Clientes mudam de idéia. A grande verdade é que no ambiente corporativo atual, sistemas de informação devem estar em constante evolução de modo a servir as necessidades de seus usuários. Este fenômeno é particular a sistemas de inforamação e foi observado inicialmente por Manny Lehman [Lehman96]. Este tipo de sistema, também conhecido como sistema do tipo E (evolutionary) se caracteriza por, uma vez instalado, tornar-se parte do meio ambiente e acabar alterando seus próprios requisitos. Sistemas do tipo E estão inseridos no mundo real, infinito e contínuo, o que determina a impossibilidade de se obter para os mesmos especificações exatas e completas. Os modelos de especificação de software que somos capazes de desenvolver são finitos (tempo finito para o desenvolvimento, memória finita para guardar, recursos limitados). Para agravar a situação, estes sistemas também devem levar em conta que o mundo real está em constante mudança de modo que algumas das hipóteses iniciais podem se tornar incorretas (sem que nos demos conta disto). Desta forma a atitude correta perante a gerência de requisitos é "preparar para mudar". Segundo Caper Jones os requistos de sofware se modificam, em média, na taxa de 2% ao mês durante as fases de projeto e codificação. Durante a fase de manutenção esta taxa pode aumentar. A mudança nos requisitos é comumente chamada de

7 volatilidade; parte das atividades da gerência de requisitos é controlar mudanças. O CMM define mudanças como: As alterações que precisam ser feitas nos requisitos e artefatos de software. É fudamental que as alterações dos requisitos sejam: Identificadas e avaliadas Avaliadas sob o ponto de vista de risco Documentadas Planejadas Comunicadas aos grupos e indivíduos envolvidos Acompanhadas até a finalização O ponto de vista do CMM é compartilhado por vários autores. Fundamental para garantir que o escopo do sistema é a manutençao de um processo de mudanças controlado. Um processo bem definido fornece aos interessados (clientes e desenvolvedores) um mecanismo formal de solicitação de mudanças nos requisitos de software. Este processo vai facilitar processos de tomada de decisão, gerência e controle de custos. O processo de controle de mudanças permite com que todas as mudanças sejam rastreadas e garante que nenhuma solicitação seja perdida ou deixada de lado. Este processo não deve ser encarado como obstáculo mas sim como um filtro que vai permitir uma gerência mais eficaz e transparente. É fundamental que este processo seja bem documentado e que faça uso de templates para solicitação de mudanças. Os templates garantem consistência e uniformidade nas solicitações, facilitam a manipulação e o armazenamento das informações em um formato único e compartilhado. A figura 1.2 ilustra um exemplo de template de solicitação de mudança. Templates para o registro de mudanças em requisitos devem conter, minimamente, informações relativas ao tipo de mudanças, à pessoa responsável pela solicitação, data e órgão de origem, e uma boa descrição da mudança em si. Idealmente também pode conter informações relativas à prioridade da mudança, em relação às diretivas do projeto e um cronograma que estabeleça a data desejada em que a mudança deveria ser implementada.

8 Não-Funcional Figura Exemplo de Registro de Solicitação de Mudança Para o gerente de requisitos o mais importante é estabelecer uma prática consistente para a mudança dos requisitos. Para tal é necessário estabelecer um processo de tratamento de mudanças. Este processo, que deve ser acordado com os membros da equipe de desenvolvimento e usuários, deve ser descrito de modo a deixar claro: Entradas - quais condições devem ser satisfeitas antes de se dar partida ao processo Tarefas - detalhar quais são as tarefas envolvidas neste processo, deixando claro quem será responsável pela sua execução e o formato em que os resultados devem ser comunicados Verificação - definir etapas onde os resultados obtidos são verificados de modo a garantir consistência e qualidade Saídas - definir um critério claro que indique que o processo chegou ao fim. Na figura 1.3 apresentamos um exemplo de processo de mudança de requisitos, proposto por Karl Wiegers.

9 Figura Processo de requisição de mudança em requisito, proposto por Wiegers.

10 1.3. Gerência da Configuração A Gerência de Configuração está comumente associada a dois tipos de tarefas: controle de versões e controle de configuração Controle de versões Por controle de versões entende-se as atividades associadas a manter, sob estrito acompanhamento, as diferentes versões de um artefato. Nas metodologias tradicionais de desenvolvimento, após clientes, usuários e equipe de desenvolvimento terem identificado e validado o conjunto de requisitos que será atendido pelo software, tem início as etapas que envolvem design, codificação, testes, etc. Mudanças em requisitos já registrados no documento de requisitos podem impactar na arquitetura proposta para o sistema, na organização de componentes, em casos de testes, em prazos e custos. Mudanças, portanto, devem ser rigorosamente controladas; o controle de versões possibilita manter a história de todas as diferentes versões dos artefatos, ao longo do ciclo de vida do sistema; isto inclui desde o levantamento inicial de informações, passa pelas atividades do processo de requisitos, e indo ainda além, durante as atividades de evolução. O controle de versões é fundamental para garantir que toda a equipe compartilha a mesma versão dos artefatos sendo trabalhados. Se isto não acontecesse, poderíamos ter a situação onde o conjunto de casos de teste sendo trabalhados pela equipe responsável pelos procedimentos de qualidade considera requisitos diferentes daqueles que estão em processo de implementação, ou mesmo já implementados. Se essa divergência entre o que foi implementado e o que vai ser testado não for identificada a tempo, os testes apontariam defeitos inexistentes, ou, no pior caso, deixariam de apontar defeitos presentes na implementação. Com o controle de versões, torna-se mais fácil garantir que todos os envolvidos no sistema em desenvolvimento compartilhem a mesma versão do documento de requisitos e dos demais artefatos utilizados durante as várias atividades associadas à criação do sistema. Quando o desenvolvimento do software é distribuído, ou terceirizado, o controle de versões torna-se mais crítico, sendo fundamental a utilização de uma ferramenta que auxilie esse trabalho. Muitas vezes a empresa contratante sofre pressões para a rápida liberação do software no mercado, para fazer frente à concorrência. A tendência é dividir o trabalho entre várias equipes, e não é incomum a situação onde uma equipe executa o processo de requisitos, passa os artefatos para uma segunda equipe efetuar projeto e implementação, enquanto uma terceira fica encarregada dos testes. Se mudanças nos artefatos de requisitos não forem comunicadas a todos os envolvidos, então a situação descrita acima tem probabilidade bastante alta de acontecer Controle da configuração do software Por controle de configuração entende-se as atividades associadas a manter, sob estrito acompanhamento, o conjunto de artefatos relacionadas a uma determinada configuração

11 do sistema. Um exemplo bastante comum é encontrado nas versões demo de muitos softwares comercializados: em relação à versão full, a versão demo possui restrições de funcionalidades, de período de utilização ou de quantidade de informações manipulada e/ou armazenada. Nestes casos, os requisitos da versão demo certamente possuem diferenças em relação aos requisitos da versão full - essas diferenças correspondem justamente às restrições colocadas pelo fabricante na versão para demonstração. Isto vale também para outros artefatos, pois essas restrições não se limitam ao conjunto de requisitos: elas podem implicar na arquitetura, nos componentes, nos casos de teste, etc. Gerencia de configuração, portanto, envolve manter controle sobre os diferentes artefatos e componentes que fazem parte de cada uma das diferentes configurações para o software em pauta. A figura 1.4 a seguir ilustra a situação onde, ao longo do tempo, foram sendo geradas diferentes revisões de uma mesma versão do software (a revisão 1.0 após a primeira alteração passou a ser denominada de 1.1, que por sua vez depois de alterada passou a ser denominada de 1.2 e assim por diante). Na mesma figura também podem ser visualizadas as revisões de outra configuração ou variante do mesmo software; revisões estas geradas a partir da revisão 1.1 da configuração principal. Todos os artefatos que correspondem a uma versão (ou revisão) devem ser consistentes uns com os outros, ou seja, todos devem refletir o mesmo conjunto de requisitos. variante configuração principal Figura diferentes revisões e configurações de um software Ferramentas para controle de versões e gerência de configuração O mercado disponibiliza diversas ferramentas que podem ser utilizadas tanto para controle de versões como para gerência de configuração. Visual SourceSafe, CVS e ClearQuest são algumas das ferramentas disponíveis com estas finalidades. Uma das mais utilizadas é o CVS - Concurrent Version System, licenciado na forma de software livre. Iremos relacionar algumas das características deste software, que são também encontradas em outras ferramentas que possuem o mesmo propósito. O CVS utiliza o conceito de repositórios para armazenamento e controle de versões de arquivos. Os diretórios que compõem a estrutura dos arquivos depositados no repositório são chamados de módulos; muitos comandos de CVS referem-se a módulos ao invés de arquivos. O administrador (gerente do projeto, por exemplo), cria o repositório e define os usuários que poderão ter acesso aos arquivos nele armazenados. É possível restringir os direitos de acesso dos usuários aos arquivos controlados. As operações de check in e check out possibilitam ao desenvolvedor executar a "retirada"

12 de um arquivo (ou de um conjunto de arquivos) para o seu próprio diretório de trabalho, fazer as modificações necessárias e recolocar os componentes modificados sob o gerenciamento do controlador de versões. O controlador, por sua vez, mantém controle sobre estas operações, verificando e informando ao usuário se alguma outra operação de modificação foi executada sobre o mesmo componente. Ferramentas deste tipo costumam trabalhar com estruturas de diretórios para o armazenamento das diferentes configurações do software sendo gerenciado; isto facilita a co-existência de diferentes configurações para um mesmo software. O espaço para armazenamento é otimizado, pois a cada nova versão, apenas as diferenças em relação à anterior são armazenadas - o CVS se encarrega de fazer a identificação das diferenças entre uma versão ou revisão e a sua anterior Rastreabilidade 3 A rastreabilidade de requisitos é uma das atividades preconizadas pelos modelos de qualidade como CMM, CMMI, MPS-BR ou ISO Na visão mais simples, rastreabilidade pode ser encarada como o conjunto de ligações entre as fontes dos requisitos, os requisitos propriamente ditos e outros artefatos como componentes e casos de teste. Por fontes dos requisitos consideramos tanto o cliente ou usuário que trouxe uma necessidade, como documentos da organização, padrões a serem seguidos e também legislação pertinente. As ligações existem nos dois sentidos, como podemos visualizar na figura 1.5 a seguir. necessidades dos clientes e documentos pré-rastreabilidade requisitos pós-rastreabilidade artefatos de design e implementação Fig. 1.5 Rastreabilidade de Requisitos As ligações denominadas de pré-rastreabilidade são aquelas relacionadas ao contexto do qual emergem os requisitos; as ligações denominadas de pós-rastreabilidade são relacionadas diretamente ao contexto técnico do processo de desenvolvimento. As ligações associadas à pré-rastreabilidade permitem identificar a origem de cada requisito e também quais os requisitos originados de uma determinada fonte (por exemplo, os requisitos originados de padrões organizacionais). As ligações associadas à pósrastreabilidade permitem identificar quais componentes (e casos de teste, por exemplo) implementam um determinado requisito, e também possibilitam saber claramente, dado um componente (ou outro artefato), quais os requisitos que ele deve atender. Outra forma de rastreabilidade associa requisitos de alto nível aos requisitos dele derivados. Requisitos de alto nível geralmente correspondem ao que Sommerville denomina de requisitos do usuário: declarações em linguagem natural ou diagramas, sobre as funções que o sistema deve fornecer e as restrições sobre as quais deve operar. 3 parte do texto sobre rastreabilidade foi originalmente publicada em [Sayão05]

13 Estes requisitos, escritos para os clientes e usuários, remetem a funcionalidades de alto nível. Já os requisitos de sistema, que são a base para o contrato entre cliente e equipe de desenvolvimento, estabelecem detalhadamente as restrições que o sistema deverá atender; são descrições mais detalhadas dos requisitos do usuário e servem de ponto de partida para o projeto do sistema. A figura 1.6 a seguir ilustra os conceitos associados a este tipo de ligação; os requisitos nela relacionados foram apresentados num exemplo de [Sommerville04]. Requisito do usuário 1. O software deve oferecer um meio de representar e acessar arquivos externos criados por outras ferramentas Requisitos de sistema 1.1. o usuário deve dispor de recursos para definir o tipo dos arquivos externos 1.2. cada tipo de arquivo externo pode ter uma ferramenta associada 1.3. cada tipo de arquivo externo pode ser representado por um ícone específico na tela do usuário 1.4. quando um usuário seleciona um arquivo externo, a ferramenta associada é ativada (para manipular adequadamente esse arquivo) Figura Ligações de rastreabilidade entre requisitos Impactos da rastreabilidade num projeto de desenvolvimento de software A rastreabilidade pode auxiliar gerentes e desenvolvedores em várias situações comuns ao desenvolvimento de software; a seguir apresentamos algumas destas situações visando mostrar o papel desempenhado pela rastreabilidade: verificação da alocação de requisitos a componentes do software: a avaliação dos elos de rastreabilidade de requisitos a artefatos de desenho e implementação identifica requisitos ainda não alocados ou implementados; verificação e validação: no processo de verificação, a avaliação das ligações entre requisitos e casos de teste possibilita localizar requisitos para os quais não foram criados procedimentos de teste. No processo de validação do software junto ao cliente, as ligações entre requisitos e componentes auxiliam a mostrar ao cliente que todos os requisitos foram atendidos pelo software desenvolvido; análise de impacto: quando uma solicitação de mudança é aceita pelo gerente do projeto, as ligações entre requisitos e componentes permitem a rápida identificação daqueles que deverão ser modificados. Isto auxilia o gerente no processo de revisão do cronograma de desenvolvimento e dos custos previstos para o software;

14 gerenciamento de riscos: a análise de riscos de um projeto inclui a identificação de riscos associados a custos e cronograma e de fatores contextuais que possam impactar em requisitos (restrições legais, por exemplo). A rastreabilidade apóia a identificação de artefatos atingidos por cada fator de risco, possibilitando a elaboração de estratégias para tratamento ou mitigação dos riscos Tipos de elos de rastreabilidade Em seu artigo sobre rastreabilidade [Ramesh01], Ramesh&Jarke propõem um metamodelo para a rastreabilidade que possibilita a captura de informações relacionadas a agentes, fontes e objetos - as três dimensões dos modelos de rastreabilidade. Nesse meta-modelo os stakeholders são ligados através de estruturas de contribuição [Gotel94] aos objetos conceituais que eles influenciam e a documentos onde tais objetos são registrados [Jarke98]. A Figura 1.7, adaptada de [Jarke98], apresenta a visão geral desse meta-modelo; note que são apresentados objetos (relacionados ao produto sendo elaborado) e artefatos que são gerados pelo próprio processo de desenvolvimento. As três dimensões consideradas correspondem a: a) Fontes: documentos que remetem à origem dos requisitos (normas, padrões, legislação pertinente, atas de reuniões,...); b) Stakeholders: são as pessoas envolvidas no Processo de Requisitos e que também possuem algum grau de interesse na rastreabilidade; c) Objetos ou artefatos: correspondem a objetos conceituais relacionados ao produto ou a artefatos gerados pelo processo de desenvolvimento. Fig. 1.7 Meta-modelo para a rastreabilidade de requisitos [Jarke98] Ramesh&Jarke ponderam que mesmo existindo uma grande variedade de elos de rastreabilidade, eles podem ser agrupados em duas categorias básicas: a) relacionados ao produto: elos que descrevem propriedades e relacionamentos dos objetos; são subdivididos em elos de satisfação e elos de dependência;

15 b) relacionados ao processo: elos relacionados ao histórico de ações executadas no próprio processo; são subdivididos em elos de evolução e elos de rationale. O propósito dos elos de satisfação é assegurar que os requisitos sejam atendidos pelo sistema, ou seja, a cada requisito foi associado um componente que deverá atendêlo. Este tipo de link é utilizado para registrar os desenhos criados para satisfazer requisitos e os componentes para os quais requisitos são alocados, para assegurar que todo componente satisfaz a requisitos, registrar fatores críticos de sucesso associados a requisitos e assegurar consistência entre saídas das diferentes fases do ciclo de vida. O propósito dos elos de evolução é registrar relacionamentos que levam de objetos existentes para objetos novos ou modificados. Este tipo de elo é útil para identificar as origens dos objetos, para melhor compreensão dos requisitos e outros objetos (através de sua história) e para registrar as modificações e histórico de refinamentos dos vários objetos. O propósito dos elos de rationale é representar as motivações subjacentes aos objetos existentes ou documentar as razões para evolução. Estes elos são utilizados para encontrar as justificativas para criação ou modificação de objetos, registrar suposições utilizadas no processo de decisão e identificar o contexto de criação de objetos. Estes elos possibilitam registrar aspectos do processo decisório, incluindo alternativas descartadas, de forma a providenciar clara compreensão da solução escolhida, facilitando a manutenção e o reuso. Em outras palavras, os elos de rationale auxiliam a gerenciar o desenvolvimento do sistema de acordo com as necessidades e objetivos organizacionais. Estes elos representam a área de atuação dos interessados, registrando as origens e o contexto no qual os objetos são desenvolvidos. E finalmente, os elos de dependência têm por propósito apoiar o gerenciamento de dependências entre requisitos ou objetos, sendo úteis para registrar a composição e hierarquia dos requisitos e apoiar o gerenciamento do impacto das alterações num requisito sobre os objetos que dele dependem Rastreabilidade de requisitos: prática Problemas relacionados ao registro e uso da rastreabilidade não são recentes: a literatura aponta para dificuldades ou problemas na prática da rastreabilidade [Gotel94a] [Ramesh01] [Zowghi01] [Damian03]. Mesmo em empresas certificadas por modelos de qualidade esta dificuldade é encontrada: Linscomb [Linscomb03] registra que nunca encontrou empresas certificadas ao nível 2 do CMM onde fossem trabalhadas matrizes de rastreabilidade completas, indicando que cada requisito foi atendido por artefatos de design, implementação e testes. Acreditamos que estes problemas acontecem, em parte, pela inadequação das ferramentas disponíveis, e em parte devido às pressões relacionadas a prazos para liberação do software no mercado. Além, é claro, da já conhecida falta de cuidado dos desenvolvedores com a documentação do processo de desenvolvimento.

16 1.4.4 Registro da rastreabilidade Ferramentas disponíveis comercialmente para o gerenciamento de requisitos utilizam matrizes de rastreabilidade como as visualizadas nas tabelas 1.1 e 1.2. A matriz de rastreabilidade pode ser implementada com uso de uma ferramenta de uso geral, como um editor de textos ou uma planilha eletrônica (muitas das ferramentas comercialmente disponíveis para a fase de requisitos utilizam alguma forma de matriz de rastreabilidade). A Tabela 1.1 apresenta um modelo simplificado de matriz de rastreabilidade. Tabela Rastreabilidade entre requisitos e entidades geradas no processo de desenvolvimento Requisito Projeto <nome_projeto> - Matriz de Rastreabilidade Documento fonte Arquitetura Componente Caso de teste No exemplo da Tabela 1.1, a primeira coluna da matriz deverá ser preenchida com os requisitos, normalmente expressos em linguagem natural e numerados seqüencialmente. As demais colunas devem representar artefatos gerados durante o processo de desenvolvimento; a correspondência nem sempre é da ordem de um para um (por exemplo, um requisito pode estar sendo verificado em diversos casos de teste, e vice-versa). Já a tabela 1.2 mostra dependências entre requisitos funcionais e não funcionais; um exemplo bastante comum para sistemas de comércio eletrônico associa requisitos não-funcionais como segurança a requisitos funcionais relacionados às transações disponíveis ao usuário do sistema. Tabela Rastreabilidade entre requisitos funcionais e não funcionais RF01 RF02 RF03 RF04 Projeto <nome_projeto> - Rastreabilidade RF versus RNF Requisito Funcional Requisito Não-Funcional NFR01 NFR02 NFR03 NFR04 NFR05 NFR06 Entre as ferramentas comerciais disponíveis, citamos a suite da IBM/Rational, que inclui o RequisitePro (centrado em documentos e utilizando matriz de rastreabilidade) para o Processo de Requisitos e outras ferramentas como o

17 AnalystStudio para o gerenciamento de requisitos. Da mesma forma, DOORS (centrado em documentos e utilizando hiperlinks para rastreabilidade) apóia tarefas relacionadas ao gerenciamento de requisitos. Registramos que RequisitePro propicia também o registro do rationale subjacente aos requisitos e sua evolução e a hierarquia entre requisitos de alto nível aos seus derivados, e que DOORS associado ao toolkit ScenarioPlus possibilita elos entre requisitos e casos de uso, em múltiplas versões, para diferentes configurações de um mesmo sistema. A figura 1.8 apresenta um exemplo de matriz de rastreabilidade, conforme registrada no RequisitePro. Fig. 1.8 Matriz de rastreabilidade entre requisitos funcionais e nãofuncionais, no RequisitePro O INCOSE, International Council on Systems Engineering, mantém uma página, periodicamente atualizada, com informações sobre as ferramentas para apoio ao registro da rastreabilidade (veja em /products/setools/tooltax/reqtrace_tools.html). Outra página, mantida pela mesma organização, apresenta um resumo sobre essas ferramentas, com informações fornecidas pelos fabricantes (http://www.paper-review.com/tools/rms/read.php) Definindo um modelo de rastreabilidade para um projeto A captura e uso dos elos de rastreabilidade devem ser adaptados às necessidades específicas de cada projeto, possibilitando uma relação custo-benefício positiva e evitando uma massa excessiva de informações relacionadas à rastreabilidade [Dömges98][Ramesh01]. A definição dos elos a serem capturados deve considerar prazos e custos do projeto em pauta, além de processos e padrões em uso na organização. Propomos a seguir, apoiados pela nossa experiência, algumas heurísticas que podem auxiliar gerente de projeto e equipe na tarefa de definir um modelo de rastreabilidade para o processo de desenvolvimento de um software específico:

18 a) definir no início do projeto, considerando a aplicação a ser desenvolvida, os tipos de elo a serem utilizados e explicitamente registrados; b) identificar as ferramentas que apoiarão o processo de rastreabilidade; c) conscientizar a equipe da importância do processo de rastreabilidade (considere que desenvolvedores não são exatamente conhecidos por seu amor à documentação [Jarke98] e que a falta de comprometimento da organização com a atividade de rastreabilidade é responsável pela falta de interesse de seus desenvolvedores nessa tarefa [Ramesh98]); d) estabelecer as entidades (artefatos, componentes, objetos, requisitos) a serem rastreadas e os pontos onde o registro deverá ser realizado; e) durante o processo de desenvolvimento, verificar se os elos de rastreabilidade estão sendo registrados pela equipe; f) utilizar e avaliar o mecanismo de extração de elos, em relação às expectativas realizadas; g) após a liberação do software, analisar criticamente com a equipe a efetividade do modelo de rastreabilidade adotado, corrigindo possíveis distorções e melhorando-o para os próximos projetos Gerência da Qualidade de Requisitos O objetivo da gerência de qualidade de requisitos é garantir que uma base de requsitos composta essencialmente de bons requisitos. Existe uma vasta literatura sobre o que torna um requisito bom, que pode ser resumida através dos seguintes critérios [Young01, Wiegers99]: Necessidade Verificável Atingível Livre de Ambiguidades Completo Consistente Rastreável Alocação Concisão Livre de Implementação Identificador único Correção Priorizável O sistema é capaz de atingir seus objetivos sem este requisito? Caso afirmativo este é um requisito desnecessário É possível verificar que este requisito está sendo atendido pelo sistema? O requisito pode ser atendido pelo sistema que está sendo desenvolvido? O requisito possui mais de uma interpretação possível? O documento de especificação do sistema contém todos os requisitos? Todos os requisitos podem ser atendedidos sem que se entre em conflito uns com os outros? A origem dos requisitos é conhecida? O requisito pode ser referenciado e localizado no sistema? O requisito pode ser alocado a um elemento ou componente do sistema? O requisito está descrito de forma simples e concisa? O requisito descreve o QUE deve ser feito sem influências de possíveis implementações? Cada requisito possui um identificador único que permita com que possamos referenciá-lo de forma única e precisa? O requisito contém toda a informação necessária que permita sua implementação? O requisito é passível de ser priorizado frente aos outros requisitos? Tabela Critérios de avaliação da qualidade de requisitos

19 Segundo o CMM, uma das atividades da área de processo chave, gerência de requisitos é a revisão dos requisitos antes antes de incorporá-los ao projeto. É necessário: Identificar requisitos incompletos ou ausentes Determinar se os requisitos estão claros, possíveis de serem implementados, consistentes e verificáveis Revisar requisitos com problemas potenciais Negociar compromissos com os grupos envolvidos A maior parte dos requisitos de software para sistemas de informação são escritos utilizando-se linguagem natural. Esta falta de formalidade na captura dos requisitos implica em uma série de potenciais problemas. Os problemas mais comuns são: Ambiguidade Falta de clareza ou duplo sentido de frases ou expressões. Este tipo de requisito leva a interpretações erradas ou inconsistentes das necessidades reais dos usuários. Exemplo: O sistema deve enviar relatórios de produtividade dos programadores, analistas ou desenvolvedores do projeto mensalmente ou quando requisitado. Neste caso fica difícil dizer se o usuário quer que seja enviado um ou três relatórios. A frequência de envio também não está clara. Se um relatório for enviado em resposta a uma solicitação, a necessidade de envio do relatório mensal permanece? Requisitos Incompletos Requisitos que deixam de fora parte da informação necessária à sua compreensão. Exemplos: Curva S (Planejado X Realizado) de um projeto Cadastro de iniciativas estratégicas Neste caso é difícil dizer se o sistema deve plotar a curva S, importar ou só exibir a figura. O mesmo pode ser dito do cadastro. O sistema é responsável por realizar o cadastro (adição, remoção e atualização), importá-lo de outro banco de dados ou apenas exibir? Requisitos Múltiplos Estes são requisitos que concatenam vários requisitos em um só. Estes requisitos devem ser separados para facilitar a tarefa de priorização e gerência de mudanças. Exemplo:

20 No evento de falha da rede elétrica, o sistema deve enviar mensagem de erro ao usuário, salvar a configuração atual do sistema e os dados entrados, até então. Neste caso podemos dividir este requisito em dois: envio de mensagem de erro e salvar a configuração do sistema. Perceba que os requisitos têm prioridades diferentes. Claro que salvar a configuração do sistema é muito mais importante em caso de falha do que avisar o usuário, que caso a rede elétrica esteja em pane já deve ter percebido o fato sozinho. Requisitos com alternativas São aqueles requisitos que não estabelecem claramente qual deve ser a ação do sistema frente a uma dada situação. De modo geral contém frases do tipo mas, com exceção, apesar, e quando. Exemplo: O sistema deve mostrar o total do pedido à medida que os códigos dos produtos vão sendo entrados no pedido, a não ser que se trate de um produto promocional. Neste caso o requisito apresenta o procedimento para duas situações diferentes e não é claro qual seria o procedimento para produtos promocionais. A solução seria quebrar este requisito em dois, cada um tratando de uma situação distinta. Requisitos mal escritos São requisitos mal redigidos que podem causar confusão e mal entendidos. Um erro muito comum é o excesso de informação Exemplos: Na improvável eventualidade de falha no sistema de refrigeração, o sistema deve mandar mensagem para a chave admin. Identificar e associar as intervenções que são complementares às outras Neste caso fica difícil até entender o requisito. A primeira sentença oferece informação relativa ao ambiente que é completamente desnecessária para o sistema. No segundo caso fica difícil entender o que o sistema deve fazer. Requisitos Inverificáveis É de conhecimento comum a gerentes de projeto a máxima "você não pode gerenciar o que não pode medir". Um requisito inverificável é escrito de modo que fica impossível de assegurar que o sistema é capaz de atênde-lo. Exemplos: O sistema X deve ser seguro O sistema C deve processar depósitos rapidamente

Rastreabilidade de Requisitos

Rastreabilidade de Requisitos ISSN 0103-9741 Monografias em Ciência da Computação n 20/05 Rastreabilidade de Requisitos Miriam Sayão Julio Cesar Sampaio do Prado Leite Departamento de Informática PONTIFÍCIA UNIVERSIDADE CATÓLICA DO

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Requisitos de Software Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti.br Requisito O que é um REQUISITO? Em software: É a CARACTERIZAÇÃO do que o

Leia mais

Qualidade de Processo de Software Normas ISO 12207 e 15504

Qualidade de Processo de Software Normas ISO 12207 e 15504 Especialização em Gerência de Projetos de Software Qualidade de Processo de Software Normas ISO 12207 e 15504 Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br Qualidade de Software 2009 Instituto

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Requisitos Cap. 06 e 07 Sommerville 8 ed. REQUISITOS DE SOFTWARE» Requisitos são descrições de serviços fornecidos pelo sistema e suas restrições operacionais. REQUISITOS DE USUÁRIOS: São

Leia mais

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Evandro Polese Alves Ricardo de Almeida Falbo Departamento de Informática - UFES Av. Fernando Ferrari, s/n, Vitória - ES - Brasil

Leia mais

Qualidade de software

Qualidade de software Faculdade de Ciências Sociais e Aplicadas de Petrolina - FACAPE Curso: Ciência da Computação Disciplina:Projeto de Sistemas Qualidade de software cynaracarvalho@yahoo.com.br Qualidade de software Qualidade

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software

Leia mais

POLÍTICA ORGANIZACIONAL

POLÍTICA ORGANIZACIONAL POLÍTICA ORGANIZACIONAL PARA DESENVOLVIMENTO DE SOFTWARE NA DR TECH Data 01/03/2010 Responsável Doc ID Danielle Noronha PoliticaOrg_DR_V003 \\Naja\D\Gerenciamento\Política Localização Organizacional Versão

Leia mais

Fundamentos de Teste de Software

Fundamentos de Teste de Software Núcleo de Excelência em Testes de Sistemas Fundamentos de Teste de Software Módulo 2- Teste Estático e Teste Dinâmico Aula 3 Teste Estático SUMÁRIO INTRODUÇÃO... 3 1. Definição... 3 2. Custo Versus Benefício...

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 1 Objetivos Apresentar os conceitos de requisitos de usuário e de sistema Descrever requisitos funcionais

Leia mais

Requisitos. Sistemas de Informações

Requisitos. Sistemas de Informações Requisitos Sistemas de Informações Definindo o Sucesso do Software Clientes satisfeitos Eles estão satisfeitos quando você: Atende às expectativas Entrega no prazo Entrega no orçamento O Sucesso começa

Leia mais

Um processo para construção de software mais transparente

Um processo para construção de software mais transparente Um processo para construção de software mais transparente Eduardo Almentero 1, and Julio Cesar Sampaio do Prado Leite 1 1 Pontifícia Universidade Católica do Rio de Janeiro, PUC - Rio, Brasil {ealmentero,

Leia mais

Definição do Framework de Execução de Processos Spider-PE

Definição do Framework de Execução de Processos Spider-PE Definição do Framework de Execução de Processos Spider-PE 1. INTRODUÇÃO 1.1 Finalidade Este documento define um framework de execução de processos de software, denominado Spider-PE (Process Enactment),

Leia mais

O GERENCIAMENTO DE REQUISITOS E A SUA IMPORTÂNCIA EM PROJETOS DE DESENVOLVIMENTO DE SOFTWARE

O GERENCIAMENTO DE REQUISITOS E A SUA IMPORTÂNCIA EM PROJETOS DE DESENVOLVIMENTO DE SOFTWARE O GERENCIAMENTO DE REQUISITOS E A SUA IMPORTÂNCIA EM PROJETOS DE DESENVOLVIMENTO DE SOFTWARE Leonardo Manoel Mendes¹, Rogério Homem da Costa², Reinaldo Lorenso³ 1. Especializando do Curso de Pós-Graduação

Leia mais

Teste de Software. Profa. Cátia dos Reis Machado catia@ifc-camboriu.edu.br

Teste de Software. Profa. Cátia dos Reis Machado catia@ifc-camboriu.edu.br Teste de Software Profa. Cátia dos Reis Machado catia@ifc-camboriu.edu.br Qualidade Garantia de Qualidade Qualidade do processo Qualidade do produto Testes Estáticos Testes Dinâmicos Teste de software

Leia mais

Introdução à Engenharia de Requisitos

Introdução à Engenharia de Requisitos Introdução à Engenharia de Requisitos Ana Luiza Ávila analuizaavila@yahoo.com.br É bacharel em Ciências da Computação pela Universidade Salvador (UNIFACS) e Mestre em Ciências da Computação pela PUC-Rio

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Centro de Informática - Universidade Federal de Pernambuco Kiev Gama kiev@cin.ufpe.br Slides originais elaborados por Ian Sommerville e adaptado pelos professores Márcio Cornélio,

Leia mais

Qualidade em Requisitos

Qualidade em Requisitos ISSN 0103-9741 Monografias em Ciência da Computação n 47/03 Qualidade em Requisitos Miriam Sayão Arndt von Staa Julio Cesar Sampaio do Prado Leite Departamento de Informática PONTIFÍCIA UNIVERSIDADE CATÓLICA

Leia mais

Gerenciamento de Configuração de Software

Gerenciamento de Configuração de Software Gerenciamento de Configuração de Software Prof. Ricardo Argenton Ramos [Baseado na apresentação do prof. Masiero ICMC-USP] Contexto para Gerência de Configuração 2 Problema dos Dados Compartilhados Desenvolvedor

Leia mais

Teste de Software Apresentação

Teste de Software Apresentação Teste de Software Apresentação Prof Daves Martins Msc Computação de Alto Desempenho Email: daves.martins@ifsudestemg.edu.br Agenda Teste de Software VV&T e Defeitos de Software Inspeção de Software Teste

Leia mais

ITIL V3 (aula 2) AGENDA: GERENCIAMENTO DE MUDANÇA GERENCIAMENTO DE LIBERAÇÃO GERENCIAMENTO DE CONFIGURAÇÃO

ITIL V3 (aula 2) AGENDA: GERENCIAMENTO DE MUDANÇA GERENCIAMENTO DE LIBERAÇÃO GERENCIAMENTO DE CONFIGURAÇÃO ITIL V3 (aula 2) AGENDA: GERENCIAMENTO DE MUDANÇA GERENCIAMENTO DE LIBERAÇÃO GERENCIAMENTO DE CONFIGURAÇÃO Gerência de Mudanças as Objetivos Minimizar o impacto de incidentes relacionados a mudanças sobre

Leia mais

Engenharia de Requisitos de Software. Visão Geral

Engenharia de Requisitos de Software. Visão Geral de Software Visão Geral João Sousa Apoio: Desenvolvimento de Sw - Como estamos? Segundo o Standish Group (CHAOS Report 2004): 34% dos projetos com sucesso. 15% dos projetos cancelados antes de completados.

Leia mais

Engenharia de Software. Gerenciamento de Requisitos. Prof. Rodolfo Miranda de Barros rodolfo@uel.br

Engenharia de Software. Gerenciamento de Requisitos. Prof. Rodolfo Miranda de Barros rodolfo@uel.br Engenharia de Software Gerenciamento de Requisitos Prof. Rodolfo Miranda de Barros rodolfo@uel.br Engenharia de Requisitos (ER) Engenharia de O termo Engenharia implica em dizer que um processo sistemático

Leia mais

ENGENHARIA DE REQUISITOS

ENGENHARIA DE REQUISITOS Universidade Federal de Santa Maria Mestrado em Computação ELC 923 Processos de Negócio e Engenharia de Requisitos Especialização em Modelagem e Desenvolvimento de Aplicações Web com JAVA ENGENHARIA DE

Leia mais

Professor: Disciplina:

Professor: Disciplina: Professor: Curso: Disciplina: Marcos Morais de Sousa marcosmoraisdesousa@gmail.com marcosmoraisdesousa.blogspot.com Sistemas de informação Engenharia de Software II Gerenciamento de Qualidade CMMI e MPS.BR

Leia mais

Essencial ao Desenvolvimento de Software

Essencial ao Desenvolvimento de Software Documento de Requisitos Essencial ao Desenvolvimento de Software De que se trata o artigo? Apresenta o documento de requisitos de software, destacando-o como um dos principais documentos pertinentes ao

Leia mais

Verificação e Validação de Requisitos

Verificação e Validação de Requisitos Verificação e Validação de Requisitos Verificação e Validação dos Requisitos Casos de Uso e Esp. Suplementar Plano e Casos de Teste Requisitos p/ Inspeção Verificar conflitos de requisitos Verificar consistência

Leia mais

Projeto de Sistemas I

Projeto de Sistemas I Instituto Federal de Educação, Ciência e Tecnologia de São Paulo Projeto de Sistemas I Professora: Kelly de Paula Cunha E-mail:kellypcsoares@ifsp.edu.br Requisitos: base para todo projeto, definindo o

Leia mais

Rational Quality Manager. Nome: Raphael Castellano Campus: AKXE Matrícula: 200601124831

Rational Quality Manager. Nome: Raphael Castellano Campus: AKXE Matrícula: 200601124831 Rational Quality Manager Nome: Raphael Castellano Campus: AKXE Matrícula: 200601124831 1 Informações Gerais Informações Gerais sobre o RQM http://www-01.ibm.com/software/awdtools/rqm/ Link para o RQM https://rqmtreina.mvrec.local:9443/jazz/web/console

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Roteiro Conceitos Engenharia de requisitos Artigo Definições de requisitos Requisitos de um sistema são descrições dos serviços que devem ser fornecidos por esse sistema e as suas

Leia mais

Engenharia de Requisitos

Engenharia de Requisitos Engenharia de Requisitos Conteúdo Definição Questionamentos Típicos Visão Geral Ciclo de Vida dos Requisitos Síntese dos Objetivos Gerência de Mudança Identificação de Requisitos Classificação de Requisitos

Leia mais

GARANTIA DA QUALIDADE DE SOFTWARE

GARANTIA DA QUALIDADE DE SOFTWARE GARANTIA DA QUALIDADE DE SOFTWARE Fonte: http://www.testexpert.com.br/?q=node/669 1 GARANTIA DA QUALIDADE DE SOFTWARE Segundo a NBR ISO 9000:2005, qualidade é o grau no qual um conjunto de características

Leia mais

Modelo para Documento de. Especificação de Requisitos de Software

Modelo para Documento de. Especificação de Requisitos de Software Modelo para Documento de Especificação de Requisitos de Software Prof. Dr. Juliano Lopes de Oliveira (Baseado na norma IEEE Std 830-1993 - Recommended Practice for Software Requirements Specifications)

Leia mais

Engenharia de Requisitos

Engenharia de Requisitos Engenharia de Requisitos Introdução a Engenharia de Requisitos Professor: Ricardo Argenton Ramos Aula 08 Slide 1 Objetivos Introduzir a noção de requisitos do sistema e o processo da engenharia de requisitos.

Leia mais

PEN - Processo de Entendimento das Necessidades de Negócio Versão 1.4.0

PEN - Processo de Entendimento das Necessidades de Negócio Versão 1.4.0 PEN - Processo de Entendimento das Necessidades de Negócio Versão 1.4.0 Banco Central do Brasil, 2015 Página 1 de 14 Índice 1. FLUXO DO PEN - PROCESSO DE ENTENDIMENTO DAS NECESSIDADES DE NEGÓCIO... 3 2.

Leia mais

O Modelo Processo de Software Brasileiro MPS-Br

O Modelo Processo de Software Brasileiro MPS-Br O Modelo Processo de Software Brasileiro MPS-Br Prof. Pasteur Ottoni de Miranda Junior Disponível em www.pasteurjr.blogspot.com 1-Estrutura do MPS-Br ( Softex, 2009) O MPS.BR1 é um programa mobilizador,

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO Santa Maria, 10 de Outubro de 2013. Revisão aula anterior Documento de Requisitos Estrutura Padrões Template Descoberta

Leia mais

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1. ARCO - Associação Recreativa dos Correios Sistema para Gerenciamento de Associações Recreativas Versão Histórico da Revisão Data Versão Descrição Autor Página

Leia mais

Políticas de Qualidade em TI

Políticas de Qualidade em TI Políticas de Qualidade em TI Aula 05 MPS.BR (ago/12) Melhoria de Processo do Software Brasileiro Prof. www.edilms.eti.br edilms@yahoo.com Agenda Descrição sumária do MPS.BR - Melhoria de Processo do Software

Leia mais

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO. Ferramenta de Apoio à Rastreabilidade de Requisitos de Software

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO. Ferramenta de Apoio à Rastreabilidade de Requisitos de Software UNIVERSIDADE FEDERAL DO RIO DE JANEIRO ESCOLA POLITÉCNICA DEPARTAMENTO DE ENGENHARIA ELETRÔNICA E DE COMPUTAÇÃO Ferramenta de Apoio à Rastreabilidade de Requisitos de Software Autor: Orientador: Co-Orientador:

Leia mais

O Impacto da Engenharia de Requisitos no Processo de Métricas. Fátima Cesarino CAIXA

O Impacto da Engenharia de Requisitos no Processo de Métricas. Fátima Cesarino CAIXA O Impacto da Engenharia de Requisitos no Processo de Métricas Fátima Cesarino CAIXA Apresentação Diferentes Cenários Desenvolvimento Software Importância do SISP Agradecimento Oportunidade Responsabilidade

Leia mais

Modelos de processos de desenvolvimento de software

Modelos de processos de desenvolvimento de software Definição Um modelo de processo de software é uma representação abstrata de um processo. Os modelos de processo podem ser desenvolvidos a partir de várias perspectivas e podem mostrar as atividades envolvidas

Leia mais

CMMI Conceitos básicos. CMMI Representações contínua e por estágios. Professor Gledson Pompeu (gledson.pompeu@gmail.com)

CMMI Conceitos básicos. CMMI Representações contínua e por estágios. Professor Gledson Pompeu (gledson.pompeu@gmail.com) CMMI Conceitos básicos 113 CMMI integra as disciplinas de engenharia de sistemas e de engenharia de software em um único framework de melhoria de processos. 114 No tocante às disciplinas de engenharia

Leia mais

Gerenciamento de Escopo na Gestão de Projetos

Gerenciamento de Escopo na Gestão de Projetos Gerenciamento de Escopo na Gestão de Projetos Airton Eustaquio Braga Junior aebjr@terra.com.br MBA Gestão de Projetos em Engenharia e Arquitetura Instituto de Pos-Graduação IPOG Goiania, GO, 02 de Setembro

Leia mais

Programa do Módulo 2. Processo Unificado: Visão Geral

Programa do Módulo 2. Processo Unificado: Visão Geral 9.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) O Processo Unificado (RUP) Processo Unificado: Visão Geral 9.2 Encaixa-se na definição geral de processo:

Leia mais

Instrutora: Claudia Hazan claudinhah@yahoo.com. Motivações para Engenharia de Requisitos (ER) Processo de Requisitos

Instrutora: Claudia Hazan claudinhah@yahoo.com. Motivações para Engenharia de Requisitos (ER) Processo de Requisitos ,PSODQWDomRGHXP 3URFHVVR GH *HVWmR GH 5HTXLVLWRV VHJXLQGRR R &00, 0, Instrutora: Claudia Hazan claudinhah@yahoo.com Agenda Motivações para Engenharia de Requisitos (ER) Processo de Requisitos Visão Geral

Leia mais

Engenharia de Software 2012/3 Aula 4 Engenharia de Requisitos

Engenharia de Software 2012/3 Aula 4 Engenharia de Requisitos Engenharia de Software Engenharia de Software 2012/3 Aula 4 Engenharia de Requisitos Thiago P. da Silva thiagosilva.inf@gmail.com Agenda Engenharia de Requisitos Níveis de Descrição dos Requisitos Tipos

Leia mais

Palavras-Chaves: engenharia de requisitos, modelagem, UML.

Palavras-Chaves: engenharia de requisitos, modelagem, UML. APLICAÇÃO DA ENGENHARIA DE REQUISITOS PARA COMPREENSÃO DE DOMÍNIO DO PROBLEMA PARA SISTEMA DE CONTROLE COMERCIAL LEONARDO DE PAULA SANCHES Discente da AEMS Faculdades Integradas de Três Lagoas RENAN HENRIQUE

Leia mais

METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS

METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS PODER JUDICIÁRIO JUSTIÇA DO TRABALHO TRIBUNAL REGIONAL DO TRABALHO DA 11ª REGIÃO SECRETARIA DE TECNOLOGIA DA INFORMAÇÃO - SETI Versão 1.0 MANAUS-AM (2010) MDS Metodologia de Desenvolvimento de Sistemas

Leia mais

PLANEJAMENTO DO ESCOPO

PLANEJAMENTO DO ESCOPO PLANEJAMENTO DO ESCOPO Dr. rer. nat. Christiane Gresse von Wangenheim, PMP Objetivo de aprendizagem desta aula Ao final desta aula, você deverá ser capaz de: Motivar a importância do planejamento de escopo.

Leia mais

Engenharia de Software Questionário sobre Engenharia de Requisitos Resolvido Prof. MSc Wagner Siqueira Cavalcante

Engenharia de Software Questionário sobre Engenharia de Requisitos Resolvido Prof. MSc Wagner Siqueira Cavalcante 1 - Q193183 ( Prova: FCC - 2011 - TRT - 19ª Região (AL) - Analista Judiciário - Tecnologia da Informação / Engenharia de Software / Análise de Requisitos; Engenharia de Requisitos; ) De acordo com Sommerville,

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 03 In a calm sea every man is a pilot. Engenharia de Software I Aula 3 Gerenciamento de

Leia mais

Os casos de uso dão conta da maioria dos requisitos de um sistema computacional.

Os casos de uso dão conta da maioria dos requisitos de um sistema computacional. Unidade 3: Modelagem de requisitos e de soluções (Parte a) 1 Casos de uso 1.1 Conceitos básicos e parâmetros de descrição Os casos de uso dão conta da maioria dos requisitos de um sistema computacional.

Leia mais

SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/

SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/ SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/ ModeloPlanoProjeto_2007_04_24 SIGECO07_PlanoProjeto_2007_09_23 Página

Leia mais

Engenharia de Requisitos

Engenharia de Requisitos UFES - Universidade Federal do Espírito Santo Engenharia de Requisitos Notas de Aula E-mail: falbo@inf.ufes.br 2012 Sumário Capítulo 1 - Introdução 1 1.1 Desenvolvimento de Software e Engenharia de Requisitos

Leia mais

Fundamentos em Teste de Software. Vinicius V. Pessoni viniciuspessoni@gmail.com

Fundamentos em Teste de Software. Vinicius V. Pessoni viniciuspessoni@gmail.com Fundamentos em Teste de Software Vinicius V. Pessoni viniciuspessoni@gmail.com Objetivos do treinamento 1. Expor os fundamentos de Teste de Software; 2. Conceituar os Níveis de Teste; 3. Detalhar sobre

Leia mais

Sommerville, Ian. Software Engineering. Editora: Addison Wesley. (capítulos sobre Requisitos)

Sommerville, Ian. Software Engineering. Editora: Addison Wesley. (capítulos sobre Requisitos) Sommerville, Ian. Software Engineering. Editora: Addison Wesley. (capítulos sobre Requisitos) Engenharia, Levantamento, Elicitação, Gerenciamento Fernando Pedrosa fpedrosa@gmail.com 1 2 Área da Engenharia

Leia mais

Modelagem de Casos de Uso (Parte 1)

Modelagem de Casos de Uso (Parte 1) Modelagem de Casos de Uso (Parte 1) Roteiro Introdução Descrição: Sistema de Ponto de Vendas Casos de Usos Atores Fluxo de Eventos Cenários Formato de Documentação de Casos de Uso Diagramas de Casos de

Leia mais

Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa

Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa Dayana Henriques Fonseca 1, Frederico Miranda Coelho 1 1 Departamento de Ciência da Computação Universidade Presidente Antônio Carlos (UNIPAC)

Leia mais

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE RESUMO Fazer um bom levantamento e especificação de requisitos é algo primordial para quem trabalha com desenvolvimento de sistemas. Esse levantamento

Leia mais

Documento de Requisitos

Documento de Requisitos UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA GRADUAÇÃO EM ENGENHARIA DA COMPUTAÇÃO Documento de Requisitos Sistema Gerenciador de Atendimento de Chamados Técnicos Grupo: Luiz Augusto Zelaquett

Leia mais

Engenharia de Requisitos. Aécio Costa

Engenharia de Requisitos. Aécio Costa Aécio Costa Um requisito é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar, para atingir os seus objetivos. (PFLEEGER, 2004) Um requisito é algo que o sistema é capaz

Leia mais

Engenharia de Requisitos

Engenharia de Requisitos Engenharia de Requisitos Processo de Eng. Requisitos p Composto por quatro (ou cinco) atividades de alto nível (Soares, 2005): p Viabilidade p Identificação. p Análise e negociação. p Especificação e documentação.

Leia mais

Qualidade de Software. Prof. Natália Oliveira M.Sc queiroz.nati@gmail.com

Qualidade de Software. Prof. Natália Oliveira M.Sc queiroz.nati@gmail.com Qualidade de Software Prof. Natália Oliveira M.Sc queiroz.nati@gmail.com Ementa Conceitos sobre Qualidade Qualidade do Produto Qualidade do Processo Garantida da Qualidade X Controle da Qualidade Conceitos

Leia mais

CobiT: Visão Geral e domínio Monitorar e Avaliar. Daniel Baptista Dias Ernando Eduardo da Silva Leandro Kaoru Sakamoto Paolo Victor Leite e Posso

CobiT: Visão Geral e domínio Monitorar e Avaliar. Daniel Baptista Dias Ernando Eduardo da Silva Leandro Kaoru Sakamoto Paolo Victor Leite e Posso CobiT: Visão Geral e domínio Monitorar e Avaliar Daniel Baptista Dias Ernando Eduardo da Silva Leandro Kaoru Sakamoto Paolo Victor Leite e Posso CobiT O que é? Um framework contendo boas práticas para

Leia mais

Engenharia de Software II: Criando a Declaração de Escopo. Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br

Engenharia de Software II: Criando a Declaração de Escopo. Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br Engenharia de Software II: Criando a Declaração de Escopo Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br Sumário Desenvolvendo o Plano de Gerenciamento do Projeto. Coletando Requisitos. Declarando

Leia mais

Capítulo X. Gerenciar Mudanças dos Requisitos. Aluizio Saiter, M. Sc.

Capítulo X. Gerenciar Mudanças dos Requisitos. Aluizio Saiter, M. Sc. Capítulo X Gerenciar Mudanças dos Requisitos., M. Sc. 2 1. Sobre a disciplina de gerência de requisitos. 2. Boas práticas em engenharia de software. 3. Introdução a gerência de requisitos. 4. Introdução

Leia mais

3 Metodologia de Gerenciamento de Riscos

3 Metodologia de Gerenciamento de Riscos 3 Metodologia de Gerenciamento de Riscos Este capítulo tem como objetivo a apresentação das principais ferramentas e metodologias de gerenciamento de riscos em projetos, as etapas do projeto onde o processo

Leia mais

Gerenciador Financeiro CITi. Gerenciador Financeiro CITi

Gerenciador Financeiro CITi. Gerenciador Financeiro CITi (Sistema de Gerenciamento Financeiro) Especificação dos Requisitos do Software Gerenciador Financeiro CITi Versão 1.0 Autores: Bruno Medeiros de Oliveira Igor Rafael Medeiros Pedro Araújo de Melo Tiago

Leia mais

Mini-Curso Gerência de Configuração Visão prática

Mini-Curso Gerência de Configuração Visão prática www.asrconsultoria.com.br Mini-Curso Gerência de Configuração Visão prática Copyright ASR Consultoria e Assessoria em Qualidade 1 Direitos de Uso do Material Material desenvolvido pela ASR Consultoria

Leia mais

Prof. Dr. Ivanir Costa. Unidade III QUALIDADE DE SOFTWARE

Prof. Dr. Ivanir Costa. Unidade III QUALIDADE DE SOFTWARE Prof. Dr. Ivanir Costa Unidade III QUALIDADE DE SOFTWARE Normas de qualidade de software - introdução Encontra-se no site da ABNT (Associação Brasileira de Normas Técnicas) as seguintes definições: Normalização

Leia mais

No artigo anterior explicamos. Desenvolvimento de Software Dirigido por Caso de Uso. Parte II: Especificando Caso de Uso

No artigo anterior explicamos. Desenvolvimento de Software Dirigido por Caso de Uso. Parte II: Especificando Caso de Uso Desenvolvimento de Software Dirigido por Caso de Uso Parte II: Especificando Caso de Uso Vinicius Lourenço de Sousa viniciuslsousa@gmail.com Atua no ramo de desenvolvimento de software há mais de 10 anos,

Leia mais

Modelagem de Requisitos com Casos de Uso. Descrever em detalhe a técnica de Modelagem com Use Cases

Modelagem de Requisitos com Casos de Uso. Descrever em detalhe a técnica de Modelagem com Use Cases Engenharia de Software Modelagem de Requisitos com Casos de Uso 1 Objetivos Descrever em detalhe a técnica de Modelagem com Use Cases 2 1 Use Case É uma forma específica de uso do sistema através da execução

Leia mais

Levantamento, Análise e Gestão Requisitos. Aula 12

Levantamento, Análise e Gestão Requisitos. Aula 12 Levantamento, Análise e Gestão Requisitos Aula 12 Agenda Miscelâneas (Parte 3): Gerenciamento dos Requisitos Mutáveis Rastreabilidade de Requisitos Processo de Gestão de Mudanças Requisitos Estáveis e

Leia mais

Instituto de Computação, Universidade Federal do Amazonas (UFAM) Manaus-AM, Brasil

Instituto de Computação, Universidade Federal do Amazonas (UFAM) Manaus-AM, Brasil Elicitação de Requisitos a partir de Modelos de Processos de Negócio e Modelos Organizacionais: Uma pesquisa para definição de técnicas baseadas em heurísticas Marcos A. B. de Oliveira 1, Sérgio R. C.

Leia mais

ESTUDO E AVALIAÇÃO DA ÁREA DE PROCESSO GESTÃO DE REQUISITOS DE ACORDO COM A NORMA CMMI NÍVEL 2 NA EMPRESA SWQUALITY

ESTUDO E AVALIAÇÃO DA ÁREA DE PROCESSO GESTÃO DE REQUISITOS DE ACORDO COM A NORMA CMMI NÍVEL 2 NA EMPRESA SWQUALITY ESTUDO E AVALIAÇÃO DA ÁREA DE PROCESSO GESTÃO DE REQUISITOS DE ACORDO COM A NORMA CMMI NÍVEL 2 NA EMPRESA SWQUALITY FABRÍCIO DE ALMEIDA OLIVEIRA ANA CRISTINA ROUILLER UFLA - Universidade Federal de Lavras

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Roteiro Inspeção Defeitos dos Software Classificação dos Erros Técnica de Leitura Ad-hoc Checklist Exercício Inspeção Inspeção de Software Definição É um método de análise estática

Leia mais

Guia do Nexus. O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado. Desenvolvido e mantido por Ken Schwaber e Scrum.

Guia do Nexus. O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado. Desenvolvido e mantido por Ken Schwaber e Scrum. Guia do Nexus O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado Desenvolvido e mantido por Ken Schwaber e Scrum.org Tabela de Conteúdo Visão Geral do Nexus... 2 O Propósito

Leia mais

Engenharia de Requisitos

Engenharia de Requisitos 1 Engenharia de Requisitos Gerenciamento de Requisitos Prof Ms Vinícius Costa de Souza www.inf.unisinos.br/~vinicius 2 Agenda Introdução Requisitos voláteis x estáveis Identificação Armazenamento Gerenciamento

Leia mais

Objetivos. Requisitos de Software. Tipos de Requisitos. O que é um requisito? Requisitos Funcionais e Não- Funcionais. Requisitos Funcionais

Objetivos. Requisitos de Software. Tipos de Requisitos. O que é um requisito? Requisitos Funcionais e Não- Funcionais. Requisitos Funcionais Objetivos de Software Gidevaldo Novais (gidevaldo.vic@ftc.br) Introduzir os conceitos do usuário e do Descrever requisitos funcionais e nãofuncionais (domínio) Apresentar um esqueleto de documento e notas

Leia mais

Projeto de Arquitetura

Projeto de Arquitetura Projeto de Arquitetura Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 11 Slide 1 Objetivos Apresentar projeto de arquitetura e discutir sua importância Explicar as decisões de projeto

Leia mais

TÍTULO: UM ESTUDO CONCEITUAL SOBRE CERTIFICAÇÃO DE SOFTWARE EMBARCADO AERONÁUTICO

TÍTULO: UM ESTUDO CONCEITUAL SOBRE CERTIFICAÇÃO DE SOFTWARE EMBARCADO AERONÁUTICO TÍTULO: UM ESTUDO CONCEITUAL SOBRE CERTIFICAÇÃO DE SOFTWARE EMBARCADO AERONÁUTICO CATEGORIA: EM ANDAMENTO ÁREA: CIÊNCIAS EXATAS E DA TERRA SUBÁREA: COMPUTAÇÃO E INFORMÁTICA INSTITUIÇÃO: FACULDADE ANHANGUERA

Leia mais

Processo de Software

Processo de Software Processo de Software Uma importante contribuição da área de pesquisa de processo de software tem sido a conscientização de que o desenvolvimento de software é um processo complexo. Pesquisadores e profissionais

Leia mais

Introdução ao OpenUP (Open Unified Process)

Introdução ao OpenUP (Open Unified Process) Introdução ao OpenUP (Open Unified Process) Diferentes projetos têm diferentes necessidades de processos. Fatores típicos ditam as necessidades de um processo mais formal ou ágil, como o tamanho da equipe

Leia mais

Gerência de Projetos de Software CMM & PMBOK

Gerência de Projetos de Software CMM & PMBOK Gerência de Projetos de Software CMM & PMBOK http://www.sei.cmu.edu/ Prefácio do CMM Após várias décadas de promessas não cumpridas sobre ganhos de produtividade e qualidade na aplicação de novas metodologias

Leia mais

Identificação rápida de gargalos Uma forma mais eficiente de realizar testes de carga. Um artigo técnico da Oracle Junho de 2009

Identificação rápida de gargalos Uma forma mais eficiente de realizar testes de carga. Um artigo técnico da Oracle Junho de 2009 Identificação rápida de gargalos Uma forma mais eficiente de realizar testes de carga Um artigo técnico da Oracle Junho de 2009 Identificação rápida de gargalos Uma forma mais eficiente de realizar testes

Leia mais

Qualidade de. Software. Definições. Qualidade do Produto ISO 9126. Processo de. Software. Modelo de Processo de. Software CMM SPICE ISO 12207

Qualidade de. Software. Definições. Qualidade do Produto ISO 9126. Processo de. Software. Modelo de Processo de. Software CMM SPICE ISO 12207 Qualidade de : Visão Geral ISO 12207: Estrutura s Fundamentais Aquisição Fornecimento s de Apoio Documentação Garantia de Qualidade Operação Desenvolvimento Manutenção Verificação Validação Revisão Conjunta

Leia mais

Gerenciamento de Qualidade

Gerenciamento de Qualidade UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Gerenciamento de Qualidade Engenharia de Software 2o. Semestre de

Leia mais

Teste de software. Definição

Teste de software. Definição Definição O teste é destinado a mostrar que um programa faz o que é proposto a fazer e para descobrir os defeitos do programa antes do uso. Quando se testa o software, o programa é executado usando dados

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Introdução à Melhoria de Processos de Software baseado no MPS.BR Prof. Maxwell Anderson www.maxwellanderson.com.br Agenda Introdução MPS.BR MR-MPS Detalhando o MPS.BR nível G Introdução

Leia mais

A IMPORTÂNCIA DO TESTE DE SOFTWARE PARA A QUALIDADE DO PROJETO

A IMPORTÂNCIA DO TESTE DE SOFTWARE PARA A QUALIDADE DO PROJETO A IMPORTÂNCIA DO TESTE DE SOFTWARE PARA A QUALIDADE DO PROJETO Autora: LUCIANA DE BARROS ARAÚJO 1 Professor Orientador: LUIZ CLAUDIO DE F. PIMENTA 2 RESUMO O mercado atual está cada vez mais exigente com

Leia mais

14 Os principais documentos de um projeto são: o termo de. 15 Elemento integrante do gerenciamento do escopo do projeto,

14 Os principais documentos de um projeto são: o termo de. 15 Elemento integrante do gerenciamento do escopo do projeto, De acordo com o comando a que cada um dos itens de 1 a 70 se refira, marque, na folha de respostas, para cada item: o campo designado com o código C, caso julgue o item CERTO; ou o campo designado com

Leia mais

No que se refere a conceitos básicos do gerenciamento de projetos, segundo o PMBoK, julgue os itens a seguir.

No que se refere a conceitos básicos do gerenciamento de projetos, segundo o PMBoK, julgue os itens a seguir. De acordo com o comando a que cada um dos itens de 1 a 70 se refira, marque, na folha de respostas, para cada item: o campo designado com o código C, caso julgue o item CERTO; ou o campo designado com

Leia mais

Realize revisões e inspeções e evite custos e esforços desnecessários

Realize revisões e inspeções e evite custos e esforços desnecessários Anais da Semana de Informática CESIT/UEA. Volume 1, Número 1. Manaus/AM: UEA Edições, 2013. ISSN 2319-0418 Realize revisões e inspeções e evite custos e esforços desnecessários Andreza Bastos Mourão 1,

Leia mais

Metodologia de Gestão e Desenvolvimento de Software. Coordenação Geral de Tecnologia da Informação

Metodologia de Gestão e Desenvolvimento de Software. Coordenação Geral de Tecnologia da Informação Metodologia de Gestão e Desenvolvimento de Software Coordenação Geral de Tecnologia da Informação 2 Índice 1. Processos Organizacionais... 7 1.1. A gestão da demanda... 7 1.2. e Responsabilidades... 7

Leia mais

Engenharia de Software III

Engenharia de Software III Departamento de Informática Programa de Pós Graduação em Ciência da Computação Laboratório de Desenvolvimento Distribuído de Software Estágio de Docência http://www.din.uem.br/~pg45640/ Qualidade de Software

Leia mais

DESENVOLVIMENTO DE SISTEMAS

DESENVOLVIMENTO DE SISTEMAS Agência Nacional de Vigilância Sanitária METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS GGTIN GESIS Brasília, julho de 2006. Página: 1 Histórico de Revisões Data Versão Descrição Autor 12/06/2006 1.0.00 Criação

Leia mais

Palavras-Chaves: Arquitetura, Modelagem Orientada a Objetos, UML.

Palavras-Chaves: Arquitetura, Modelagem Orientada a Objetos, UML. MODELAGEM ORIENTADA A OBJETOS APLICADA À ANÁLISE E AO PROJETO DE SISTEMA DE VENDAS ALTEMIR FERNANDES DE ARAÚJO Discente da AEMS Faculdades Integradas de Três Lagoas ANDRE LUIZ DA CUNHA DIAS Discente da

Leia mais

Qualidade de Software: Visão Geral

Qualidade de Software: Visão Geral Qualidade de Software: Visão Geral Engenharia de Software 1 Aula 05 Qualidade de Software Existem muitas definições de qualidade de software propostas na literatura, sob diferentes pontos de vista Qualidade

Leia mais