GerenciaDeRequisitos01 Alterado

Caderno do Aluno
Gerncia de Requisitos com Casos de Uso
re.qui.si.to: adj (lat requisitu) desus Requisitado, 1. Exigncia imprescindvel para a consecuo de certo fim.
Notas:

Copyright 2010. Todos os direitos reservados. Este documento no poder ser reproduzido, na ntegra ou em parte, sem prvia autorizao por escrito do autor.
Caderno do Aluno
Diviso do Curso
(Mdulo 1-Sobre este Curso e Boas prticas da Engenharia de Software (Mdulo 2)-Introduo a GR (Mdulo 3)-Identificao e Descoberta de Requisitos (Mdulo 4)-Documentao de Requisitos (Mdulo 5)-Modelagem de Casos de Uso (Mdulo 6)-Expanso dos Casos de Uso (Mdulo 7)-Prototipao dos Casos de Uso;
Prof. Msc Joo Caldas Jnior
Notas:

Caderno do Aluno
Mdulo 0: Sobre este Curso
Notas:
A gerncia de Requisitos semelhante ao trabalho do Escultor que Esculpe um material bruto at captar uma forma Visual interessante,da mesma forma , o gerenciamento de Requisitos precisa pegar dados brutos, elicitar , descobrir Investigar at chegar a esta forma interessante, a qual seria As necessidades do usurio, este ratreamento levar A um entendimento mais acurado entre o Cliente e o Desenvolvedor.

Caderno do Aluno
Pblico-Alvo
Engenheiro de Performance Analistas Gerente de Projeto
Engenheiro de Testes
Engenheiro de verses
Desenvolvedor
Notas:

Caderno do Aluno
Objetivos
Aplicar gerenciamento de requisitos na produo de uma definio clara que corresponda aos requisitos do software final; Capturar e documentar requisitos com as tcnicas do modelo Use-Case; Definir uma hierarquia de documentos e padres para definir nveis de requisitos para um produto;
Notas:

Caderno do Aluno
Objetivos
Usar atributos de requisitos e links de rastreabilidade para ajudar a gerenciar o escopo e as mudanas durante o ciclo-de-vida do produto; Entender como os requisitos impactam no design, teste e na documentao das atividades do usurio.
Notas:

Caderno do Aluno
Entendendo suas Necessidades
O que voc almeja com esse curso
Notas: Como determinar o requisito de maior prioridade?

BAIXA,MDIA,ALTA,CRTICO,IMPORTANTE,TIL,FLOREIO

Caderno do Aluno
Mdulo 1:As 6 Boas Prticas
Notas:

Caderno do Aluno
Objetivos
Identificar passos para Entender e Solucionar problemas da Engenharia de Software; Explicar as 6 Boas Prticas; Apresentar o RUP no contexto das 6 Boas Prticas.
Notas:

Caderno do Aluno
Sintomas de Problemas no Desenvolvimento de Software
Necessidades de negcio ou de usurios no atendidas Requisitos mal definidos Mdulos que no se integram Descoberta tardia de falhas Interface com o usurio de baixa qualidade Esforo da equipe no coordenado Problemas relativos ao release gerado
Notas:

10
Caderno do Aluno
Boas Prticas da Engenharia de Software
Desenvolvimento iterativo
Gerncia de Requisitos
Arquitetura Modelagem Visual Componentizada
Contnua Cont Verificao de Verifica Qualidade
Controle de Mudanas Mudan
Notas:
Insight Nas seis melhores prticas, o desenvolvimento iterativo influencia as outras prticas. Assim como as outras 5 prticas incrementam o desenvolvimento iterativo. Por exemplo,num desenvolvimento iterativo o uso de requerimentos inadequados pode com certeza falhar no desenvolvimento de uma soluo adequada. Por isso, o uso de somente algumas das prticas desaconselhvel.

11
Caderno do Aluno
Prtica 1: Desenvolvimento Iterativo
Desenvolvimento Iterativo
Arquitetura Componentizada
Modelagem Visual
Verificao Contnua da Qualidade
Controle de Mudanas
Notas:
Insight(1) O desenvolvimento iterativo uma tcnica usada para entregar partes de um sistema em sucessivos releases, at que todo o sistema tenha sido completado e entregue.Cada release tratado como se fosse um pacote de funcionalidades, desenvolvido num perodo determinado chamado iterao. Insight(2) O processo em cascata tende a massacrar os riscos do projeto,pois tem um prazo de entrega de um produto executvel muito longo,podendo deixar que os riscos do projeto sejam identificados tarde demais. Por esse motivo, o processo iterativo foi criado justamente para fazer com que o processo em cascata seja aplicado iterativamente.

12
Caderno do Aluno
O processo iterativo produz um produto(executvel) construdo,testado e integrado.
Captura de Requisitos Anlise e Projeto An Planejamento Implementao Implementa Escopo Inicial do projeto Iterao N Itera
Desenvolvimento Avaliao Avalia Teste
Notas:
Insight(1) O processo iterativo enfatiza o processo de desenvolvimento das funcionalidades que oferecem um maior risco para o projeto, incluindo integrao e testes.Esse processo feito atravs da anlise e seleo dos casos de uso identificados no projeto. Para cada caso de uso deve ser aplicado o processo em cascata iterativamente,at a entrega de todos os casos de uso de maior risco. O desenvolvimento iterativo inicia primeiro na produo da arquitetura,permitindo que a integrao ocorra na fase de projeto, e permitindo que os riscos de arquitetura sejam identificados e resolvidos no inicio da produo destes. Geralmente, uma abordagem iterativa superior a uma abordagem linear ou em cascata, por vrios motivos. Os riscos so reduzidos mais cedo, pois os elementos so integrados progressivamente. As tticas e os requisitos variveis so acomodados. A melhoria e o refinamento do produto so facilitados, resultando em um produto mais robusto. As organizaes podem aprender a partir dessa abordagem e melhorar seus processos. A capacidade de reutilizao aumenta.

13
Caderno do Aluno
Prctica 2: Gerncia de Requisitos
Modelagem Visual
Verificao Contnua de Qualidade
Controle de Mudanas
Notas:

14
Caderno do Aluno
Gerenciamento de Requisitos
Notas:

15
Caderno do Aluno
Garantindo: > Resoluo do problema correto > Construo do sistema correto Pela adoo de uma abordagem sistemtica para: > Elicitar > Organizar > Analisar > Modelar > Gerenciar os requisitos (que podem mudar ao longo do projeto) de uma aplicao
Notas:

16
Caderno do Aluno
Gerenciamento de Requisitos
Aspectos de Gerncia de Requisitos > Analisar o problema; > Entender as necessidades dos Usurios; > Definir o sistema; > Gerenciar o escopo do sistema; > Refinar as definies do Sistema; > Gerenciamento dos requisitos variveis (para construir o sistema correto).
Notas:

17
Caderno do Aluno
Prtica 3: Uso de Arquitetura Componentizada
Gerncia de Arquitetura Verify Requisitos Componentizada Quality
Modelagem Visual
Controle de Mudanas
Notas:
3. Arquitetura baseada em componentes Quando falamos em arquitetura de um sistema de software, estamos falando de sua organizao, quais so seus elementos estruturais, suas respectivas interfaces e como trabalham em conjunto para resolver um problema proposto. Quando falamos em componentes, estamos falando de um grupo de cdigo que realiza uma clara e especfica funo dentro do contexto de um sistema, e que possui uma interface de acordo com uma arquitetura bem definida.

18
Caderno do Aluno
Arquiteturas componentizadas, resilientes

Resilientes (resistem flexivelmente adversidade) > Atendem a requisitos atuais e futuros; > Melhoram a Extensibilidade; > Facilitam reuso; > Encapsulam as dependncias do Sistema Componentizadas > Reuso ou Customizao de Componentes; > Utilizao de Componentes disponveis Comercialmente; > Evoluo incremental do Software existente.
Notas:
A abordagem iterativa permite identificar componentes progressivamente e decidir quais desenvolver, quais reutilizar e quais comprar. O foco na arquitetura de software permite montar a estrutura, os componentes e como eles se integram, incluindo os padres e os mecanismos fundamentais atravs dos quais eles interagem. Conceitos como pacotes, subsistemas e camadas so utilizados durante a disciplina Anlise e Design para organizar componentes e especificar interfaces. Os testes so primeiramente organizados em componentes e, em seguida, em conjuntos maiores de componentes integrados.

19
Caderno do Aluno
Prtica 4: Modelagem Visual de Software
Modelagem Visual
Verificao contnua da Qualidade
Controle de Mudanas
Notas:
4. Modelagem visual Um modelo uma simplificao da realidade, que completamente descreve um sistema a partir de uma perspectiva particular. Nas reas mais tradicionais da engenharia, modelos vem sendo usados a muito tempo, e determinam uma forma de melhor entender e representar aquilo que se pretende construir. Normalmente um nico modelo no suficiente para representar por completo um determinado produto, existindo para isso diferentes modelos de acordo com o que se pretende representar (Ex: Circuito eletrnico, carta de tempos, etc). Modelagem importante porque ajuda a equipe de desenvolvimento a visualizar, especificar, construir e documentar a estrutura e comportamento da arquitetura do sistema. A utilizao de uma linguagem padronizada de modelagem tal como a UML, ajuda a evitar problemas de interpretao dos documentos gerados durante o desenvolvimento.

20
Caderno do Aluno
Por que usar Modelagem Visual?

Para capturar Estrutura e Comportamento; Para mostrar como os elementos do sistema se integram; Para manter consistncia entre projeto e implementao; Para esconder ou Expor detalhes apropriadamente; Para promover uma comunicao no-ambgua > UML: uma linguagem para todos os papis envolvidos
Notas:

21
Caderno do Aluno
Diagramas so Vises de um Modelo
Use Case Use Case Use Case Use Case Diagrams de Diagrama Diagrams de Diagrama Diagrams Diagrams Atividades Atividades Scenario Scenario Scenario Scenario Diagrams de Diagrama Diagrams de Diagrama Diagrams Diagrams Seqncia Seqncia
Use Case Use Case Use Case Use Case Diagrams de Diagrama Diagrams de Diagrama Diagrams Diagrams Caso de Uso Caso de Uso
State State State State Diagrams de Diagrama Diagrams de Diagrama Diagrams Diagrams Classes Classes
State State State State Diagrams de Diagrama Diagrams de Diagrama Diagrams Diagrams Objetos Objetos
Modelo
State State State State Diagrams de Diagrama Diagrams de Diagrama Diagrams Diagrams Estados Estados
Scenario Scenario Scenario Scenario Diagrams de Diagrama Diagrams de Diagrama Diagrams Diagrams Colaborao Colaborao
Diagrama de Diagrama de Implantao Implantao
Component Component Component Diagrams Component Diagrams Diagrama de Diagrams Diagrama de Diagrams
Componentes Componentes
Notas:
Um modelo uma descrio completa de um Sistema de uma perspectiva particular Os diagramas esto em grupos de cores porque existem : os Estticos que no exprimem Comportamento e os Dinmicos Ademais voc poder detalhar um Caso de Uso usando um Diagrama de Atividades

22
Caderno do Aluno
Modelagem Visual Usando Diagramas UML

Use-Case Diagram
Use Case 1
add( ) delete( )
Class Diagram
DocumentList FileMgr add( ) delete( ) Document name : int docid : int numField : int get( ) open( ) close( ) read( ) sortFileList( ) create( ) fillDocument( ) read() fill the code.. fetchDoc( ) sortByName( ) FileList fList
State Diagram
add file [ numberOffile==MAX ] / flag OFF Openning
add file
Writing
Actor A Use Case 2
close file
Actor B
close file Reading
rep Repository (from Persistence) name : char * = 0 readDoc( ) readFile( ) read( ) open( ) create( ) fillFile( ) File GrpFile
Closing
read( )
Domain Expert
Use Case 3
UI
<<entity>> Customer name addr receive() withdraw() fetch() send()
MFC
Class
Deployment Diagram
- 95 : - N T: - - : - -, - - IBM : -, -
DocumentApp
RogueW ave
Repository
DocumentList
Window 95
Window s 95 Window s 95
9: s ortByName ( )
Persistence
global
User Interface Definition
FileManager
mainWnd : MainWnd
1: Doc view reques t ( )
L
- .EXE -
Window s NT
2: fetc hDoc ( ) 4: c reate ( ) 8: fillFile ( )
gFile : GrpFile
user : fileMgr : FileMgr

3: c reate ( ) 6: fillDoc ument ( )
Package Diagram
Document
- .EXE
Solaris
Alpha U N IX -.EXE Window s NT
GraphicFile File FileList
IBM Mainframe
7: readFile ( ) 5: readDoc ( )
document : Document repository : Repository
Collaboration Diagram
mainWnd user fileMgr : FileMgr document : Document gFile repository
- . 1: Doc view request ( )
Component Diagram
Forward Engineering (Code Generation) and Reverse Engineering
2: fetchDoc( )
3: create ( )
4: create ( )
Source Code edit, compile, debug, link

5: readDoc ( ) 7: readFile ( )
- - .
6: fillDocument ( )
8: fillFile ( )
- - .
9: sortB yName ( )
Sequence Diagram
Executable System
Notas:
Neste diagrama enfatiza-se que a partir da Modelagem visual, teremos uma forma de integrao , onde veremos. O Sistema sob vrias perspectivas, tais como:esttica,dinmica,arquitetural e de Implantao. Assim, poderemos , por exemplo , detalhar um Caso de Uso usando o Diagrama de Seqncia nas partes mais crticas

23
Caderno do Aluno
Prtica 5: Verificao contnua da qualidade
Modelagem Visual
Verificao Verifica contnua da cont Qualidade
Controle de Mudanas
Notas:
5. Verificao contnua da qualidade do software Quanto mais tempo demoramos para encontrar o problema em um software, mais caro ficar sua reparao. O conserto de bugs identificados aps a entrega final do produto, pode gerar grande sobrecarga de trabalho e custo, alm da impiedosa sina da criao de um software de baixa qualidade. Por esta razo muito importante avaliar continuamente a qualidade de um sistema de software, garantindo sua funcionalidade, confiabilidade e performance pretendida. Uma prtica que ajuda a garantir tal qualidade, sem dvida a realizao massiva de testes. Os casos de uso, citados para orientar o processo de levantamento de requisitos, constituem um importante recurso tambm para a realizao de testes.

24
Caderno do Aluno
Verificao contnua da qualidade
Os problemas de Software so de 100 a 1000 vezes mais caros para manter e consertar aps o desenvolvimento
Custo
Desenvolvimento
Deployment
Notas:

25
Caderno do Aluno
Dimenses da Qualidade de Software a serem testadas
Tipo
Confiabilidade
Por que?
Minha aplicao invade memria?
Como?
Ferramentas de anlise e instrumentao do cdigo Casos de Testes para cada cenrio implementado Checar performance para cada use case/cenrio implementado Testar performance de todos os casos de uso sob carga e pior cenrio
Funcionalidade Minha aplicao faz o que requerido? A performance de minha aplicao aceitvel?
Performance da Aplicao
Performance do Sistema
Meu sistema suporta a carga de produo ?
Notas:

26
Caderno do Aluno
Teste cada iterao / Incremente os Testes
Requisitos
Iterao 1 Itera
Iterao 2 Itera
Iterao 3 Itera Iterao 4 Itera Teste Suite 3 Teste Suite 4
Testes automatizados
Teste Suite 1 Teste Suite 2
Notas:

27
Caderno do Aluno
Prtica 6: Controle de Mudanas
Modelagem Visual
Controle de Mudanas Mudan
Notas:
6. Controle de alteraes no software Sistemas grandes, desenvolvidos por vrias equipes, muitas vezes localizadas em vrios locais diferentes, podem atingir rapidamente um estado de caos, caso no exista um controle disciplinado das alteraes ocorridas no software. Utilizada em conjunto com o desenvolvimento iterativo, proporciona a obteno de uma linha base de cdigo testada a cada iterao, permitindo uma rpida localizao da origem de novos problemas, evitando assim a propagao de erros gerada por uma alterao.

28
Caderno do Aluno
Prtica 6 Gerncia de Mudanas
Insight
>
>
>
O grande desafio quando da construo de um sistema que voc deve interagir com diversas equipes, organizadas em diferentes reas, possivelmente em diferentes espaos fsicos, etc.; Na ausncia do controle das disciplinas rapidamente o processo de desenvolvimento vira um caos; No RUP, a gerncia de mudanas descreve como ir ao encontro desse grande desafio.
Notas:

29
Caderno do Aluno
O RUP implementa as boas prticas
Notas:

30
Caderno do Aluno
Como o RUP implementa as 6 boas prticas

Abordagem iterativa Diretrizes para atividades e produtos de trabalho (artefatos) Processo focado na arquitetura Casos de Uso que direcionam o projeto, implementao e testes Modelos que abstraem o sistema
Notas:

31
Caderno do Aluno
Definio de processo baseado em equipe
Um processo define quem faz o que e quando e como para atingir uma meta
Mudana de Requisitos Processo de Engenharia de Software Mudana de Sistema
Notas:

32
Caderno do Aluno
Fases no Processo
Fases
Concepo Elaborao Construo Transio
tempo
O Rational Unified Process tem 4 fases:

> >
> >
Concepo - Define o escopo do projeto; Elaborao Planeja projeto, especifica caractersticas(features), baseline da arquitetura atravs de um prottipo; Construo Constri o produto; Transio- Transio do produto para o usurio final utilizar.
Notas:

33
Caderno do Aluno
Disciplinas guiam o desenvolvimento iterativo
Workflow Captura de Requisitos
Workflow Anlise e Projeto
Notas:

34
Caderno do Aluno
Notao
Papel que pode ser desempenhado por pessoa ou grupo
Unidade de trabalho executado por um papel
Atividade Papel Pedao de informao produzido, modificado ou usado pelo processo Artefato
Notas:

35
Caderno do Aluno
Apresentando o processo, comentar:

Disciplinas produzem modelos Abordagem iterativa versus disciplina Disciplinas guiam o desenvolvimento iterativo Notao Papis so usados para planejamento de recursos Papis executam atividades e produzem artefatos Viso Geral dos Conceitos do RUP
Notas:

36
Caderno do Aluno
RUP: Framework para Gerncia de Requisitos
Notas:
O Rational Unified Process ou produto RUP um framework de um processo de engenharia de software. Ele fornece uma abordagem disciplinada para atribuir tarefas e responsabilidades dentro de uma organizao de desenvolvimento. Seu objetivo garantir a produo de software de alta qualidade que atenda s necessidades dos seus usurios finais dentro de um cronograma e um oramento previsveis. O RUP oferece oito disciplinas que fornecem orientao sobre tudo, desde a modelagem de negcios para gerenciamento de projetos. A finalidade da disciplina Requisitos fornecer orientaes sobre: Estabelecer e manter concordncia com os clientes e outras partes interessadas sobre o que o sistema deve fazer. Oferecendo aos desenvolvedores do sistema com um melhor entendimento dos requisitos do sistema. Definir os limites da (delimitar) o sistema. Fornecendo uma base para planejar o contedo tcnico das iteraes. Fornecendo uma base para estimar o custo eo tempo para desenvolver o sistema. O RUP apenas um framework porque no h como dois projetos serem desenvolvidos da mesma maneira. Cada projeto tem necessidades diferentes de desenvolvimento.

37
Caderno do Aluno
Requisitos Disciplina: Detalhes Workflow
Notas:
Este diagrama mostra a disciplina de requisitos do Rational Unified Process . As principais atividades da disciplina Requisitos so chamados os detalhes do fluxo de trabalho.

38
Caderno do Aluno
Papis e Artefatos
Notas:
No RUP, o papel do analista de sistema lidera e coordena a elicitao de requisitos e modelagem de casos de uso, destacando a funcionalidade do sistema e delimita o sistema. Por exemplo, estabelece que os atores e casos de uso existentes e como eles interagem. Os requisitos detalhes especificador papel a especificao de uma parte da funcionalidade do sistema, descrevendo o aspecto requisitos de um ou vrios casos de uso e outros requisitos de software de apoio. O especificador de requisitos tambm pode ser responsvel por um pacote de casos de uso e manter a integridade do pacote. Recomenda-se que os requisitos especificador responsvel por um pacote de casos de uso tambm responsvel por seus casos de uso constante e atores. Outro papel importante na disciplina de Requisitos o revisor requisitos (no mostrado aqui), que planeja e realiza a anlise formal do modelo de casos de uso e outros requisitos.

39
Caderno do Aluno
Quais Artefatos so usados?

Onde o problema definido? Onde os agentes e os usurios so listados? Onde os ambientes e plataformas so identificados? Onde os requisitos no funcionais So localizados? Onde o Casos de Uso so descritos? Onde a terminologia registrada? Onde as necessidades do cliente so capturadas?
Viso
Especificao Suplementar Especificao Casos de Uso
Glossrio
Necessidades Do Cliente
Notas:
H um nmero de diferentes artefatos que voc precisa para trabalhar com gerenciamento de requisitos, quando o seu software. Acima est uma lista breve para ajud-lo a visualizar o que vai onde. Seu Plano de Gerenciamento de Requisitos determina que os artefatos que voc usa para capturar suas necessidades. O Plano de Gerencia de Requisitos deve ser tratado prioridade e utilizado para guiar o processo de requisitos.

40
Caderno do Aluno
Uma disciplina: Muitos caminhos

Concepo
Elaborao
Construo
Notas:
Em um processo iterativo, voc faz um passe em cada disciplina, uma vez por iterao. Durante cada passagem se deve investir o mesmo nvel de esforo em cada atividade. Por exemplo, nas iteraes Iniciao, voc gasta uma grande quantidade de esforo na anlise do problema e pouco no refinamento da definio do sistema. Nas iteraes subsequentes, voc gasta menos tempo na anlise do problema e muito mais tempo para aperfeioar a definio do sistema. Todo projeto de software diferente, de modo que cada projeto deve ser gerido de forma diferente. Um projeto pequeno, com pouco risco no precisa do mesmo nvel de formalismo como um grande projeto que tem alto risco. O RUP no um processo one-size-fits. Destina-se a ser personalizado. Cada personalizao chamado de "Caso de Desenvolvimento." A detalhes do desenvolvimento, atividades realizadas e artefatos produzidos em cada disciplina para um projeto especfico. O plano de iterao, quando descreve cada artefato produzido durante o projeto. Tipicamente, uma organizao que cria um nmero de casos de padro de desenvolvimento, por exemplo, uma para pequenos projetos de baixo risco e outra para o projeto de grande risco mdio. Quando um novo projeto iniciado, categorizado e um caso de desenvolvimento escolhido. O processo de desenvolvimento descreve quando e quais artefatos sero produzidos. O processo de desenvolvimento escolhido pode ser personalizado para torn-lo relevante para o projeto a ser realizado.

41
Caderno do Aluno
Reviso
1. 2. Qual o impacto que cada uma das boas prticas trazem a um projeto de software? Quais documentos e qual relevncia de cada um deles na disciplina de Gerncia de Requisitos no RUP? Quais fases do RUP envolvem a elicitao, anlise e modelagem de requisitos?
3.
Notas:
Respostas 1.
2.
3.

42

GerenciaDeRequisitos01 Alterado

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

GerenciaDeRequisitos01 Alterado

Enviado por

Direitos autorais:

Formatos disponíveis

Caderno do Aluno

Gerncia de Requisitos com Casos de Uso

Gerncia de Requisitos com Casos de Uso

Gerncia de Requisitos com Casos de Uso

Prof. Msc Joo Caldas Jnior

Gerncia de Requisitos com Casos de Uso

Mdulo 0: Sobre este Curso

Gerncia de Requisitos com Casos de Uso

Prof. Msc Joo Caldas Jnior

Gerncia de Requisitos com Casos de Uso

Engenheiro de Performance Analistas Gerente de Projeto

Gerncia de Requisitos com Casos de Uso

Prof. Msc Joo Caldas Jnior

Gerncia de Requisitos com Casos de Uso

Gerncia de Requisitos com Casos de Uso

Prof. Msc Joo Caldas Jnior

Gerncia de Requisitos com Casos de Uso

Gerncia de Requisitos com Casos de Uso

Prof. Msc Joo Caldas Jnior

Gerncia de Requisitos com Casos de Uso

Entendendo suas Necessidades

O que voc almeja com esse curso

Gerncia de Requisitos com Casos de Uso

Prof. Msc Joo Caldas Jnior

Notas: Como determinar o requisito de maior prioridade?

Gerncia de Requisitos com Casos de Uso

Mdulo 1:As 6 Boas Prticas

Gerncia de Requisitos com Casos de Uso

Prof. Msc Joo Caldas Jnior

Gerncia de Requisitos com Casos de Uso

Gerncia de Requisitos com Casos de Uso

Prof. Msc Joo Caldas Jnior

Gerncia de Requisitos com Casos de Uso

Sintomas de Problemas no Desenvolvimento de Software

Gerncia de Requisitos com Casos de Uso

Prof. Msc Joo Caldas Jnior

Gerncia de Requisitos com Casos de Uso

Boas Prticas da Engenharia de Software

Arquitetura Modelagem Visual Componentizada

Contnua Cont Verificao de Verifica Qualidade

Controle de Mudanas Mudan

Gerncia de Requisitos com Casos de Uso

Prof. Msc Joo Caldas Jnior

Gerncia de Requisitos com Casos de Uso

Prtica 1: Desenvolvimento Iterativo

Verificao Contnua da Qualidade

Gerncia de Requisitos com Casos de Uso

Prof. Msc Joo Caldas Jnior

Gerncia de Requisitos com Casos de Uso

Desenvolvimento Avaliao Avalia Teste

Gerncia de Requisitos com Casos de Uso

Prof. Msc Joo Caldas Jnior

Gerncia de Requisitos com Casos de Uso

Prctica 2: Gerncia de Requisitos

Verificao Contnua de Qualidade

Gerncia de Requisitos com Casos de Uso

Prof. Msc Joo Caldas Jnior

Gerncia de Requisitos com Casos de Uso

Gerncia de Requisitos com Casos de Uso

Prof. Msc Joo Caldas Jnior

Gerncia de Requisitos com Casos de Uso

Gerncia de Requisitos com Casos de Uso

Gerncia de Requisitos com Casos de Uso