Aula 2 - Mapeamento de Processos - Esw

1 semestre de 2014
Engenharia de Requisitos
Professor Ricardo Dematt
IFSP Unidade Campinas
1 semestre de 2014
Aula 3
Engenharia de Software
Conceitos Bsicos
Um dos resultados da Engenharia de Software a
definio de aspectos como funcionalidade e
desempenho do software.
O trabalho essencial do analista de sistemas acomodar
os requisitos de funcionalidades e desempenho da forma
mais eficiente possvel, tendo que, para isto, adquirir e/ou
desenvolver os componentes de software.
A dificuldade que surge na Engenharia de Software
a falta de padronizao nos componentes de software,
uma vez que, na maior parte dos projetos, estes
componentes so "customizados" para atender s
exigncias de software do sistema a ser desenvolvido.
3
Conceitos Bsicos
A Engenharia de Software envolve as seguintes fases:
1. Definio
2. Desenvolvimento do Software
3. Verificao, Entrega e Manuteno
4. Integrao
4
Conceitos Bsicos
A Engenharia de Software envolve as seguintes fases:
1. Definio
iniciada com o Planejamento do Desenvolvimento do
Software, obtendo um documento de Plano do Software, o
qual ser produzido e revisado pelo Gerente do Projeto;
Ainda nesta fase realizada a Anlise de Requisitos do
Software, a qual vai permitir que funes, dentro do
sistema como um todo sero atribudas ao software;
A ltima tarefa relacionada a esta fase a reviso da
Especificao de Requisitos do Software, o qual o
documento resultante da Anlise de Requisitos;
5
Conceitos Bsicos
2. Desenvolvimento do Software
a fase que tem, como ponto de partida, os documentos produzidos
na fase anterior, particularmente, o Plano do Software e a
Especificao de Requisitos do Software;
Com base nestes documentos, inicia-se a etapa de Projeto do
Software, onde sero descritos aspectos relacionados ao
funcionamento do software como a sua arquitetura e as estruturas de
dados;
Aps avaliada esta definio, inicia-se a etapa de Projeto Detalhado,
onde os aspectos algortmicos e comportamentais do software so
definidos;
Finalmente, a etapa de codificao encaminhada, seja com base
no uso de uma linguagem de programao clssica ou com o
auxlio de uma ferramenta CASE, o resultado desta etapa sendo
a listagem dos programas-fonte do software em desenvolvimento;
6
Conceitos Bsicos
3. Verificao, Entrega e Manuteno
a ltima fase do processo, a qual envolve as atividades
de teste do software, preparando-o para a entrega;
Uma vez entregue, inicia-se, ao longo de toda a vida
til do software a etapa de manuteno, a qual
permitir manter o software em funcionamento a partir
da correo de novos erros que tenham sido
detectados com o software em funcionamento, da
introduo ou melhorias de funes do software, da
adaptao do software para novas plataformas de
hardware existentes.
7
Conceitos Bsicos
4. Integrao de Sistemas (opcional)
O conjunto de atividades a ser desenvolvido nesta
etapa o de conexo dos diferentes subsistemas
construdos ou adquiridos para compor o sistema.
uma atividade bastante complexa, devido
principalmente, grande diversidade de tecnologias
envolvidas na concepo dos diferentes sistemas.
Um problema comumente encontrado nesta etapa o
mal funcionamento de um subsistema como
consequncia de uma definio imprecisa de
funcionalidade de outro subsistema.
8
Definio de Requisitos
1. O que so os requisitos de software ?
Um requisito consiste da definio documentada de uma
propriedade ou comportamento que um produto ou servio
particular deve atender.
o processo de estabelecer os servios que o cliente
requer de um sistema e as restries sob as quais deve
ser desenvolvido e operar.
Requisitos so as descries das funes e as suas
respectivas restries.
Pode variar de uma declarao abstrata de alto nvel, de
uma funo que o sistema deve fornecer ou de uma
restrio do sistema, a uma definio detalhada,
matematicamente formal, de uma funo do sistema.
9
Requisitos
Requisitos so uma especificao do que deve ser construdo.
So descries de como o sistema deve se comportar, ou uma
propriedade ou atributo do sistema. Podem ser uma restrio ao
processo de desenvolvimento.
O diagrama abaixo ilustra todas essas possibilidades.
10
Requisitos
11
Requisitos
O Modelo V uma variao do modelo cascata, que
demonstra como as atividades de testes esto
relacionadas com analise e projeto.
12
Requisitos
Modelo V
A conexo entre os lados esquerdo e direito do modelo em
V implica que, caso sejam encontrados problemas durante
a verificao e a validao, o lado esquerdo do V pode ser
executado novamente para corrigir e melhorar os
requisitos, o projeto e a codificao, antes da execuo
das etapas de testes que esto no lado direito.
Em outras palavras o modelo V torna mais explicitas
algumas iteraes e repeties do trabalho, ocultas no
modelo cascata.
Enquanto o o enfoque do modelo cascata esta nos
documentos e nos artefatos, o enfoque do V esta na
atividade e na correo.
13
Importncia dos Requisitos
O cenrio de desenvolvimento de software atual e o cenrio
idealizado junto engenharia de software ainda esto
distantes.
Vrios fatores contribuem para isso, podemos citar:
O no uso e o mau uso dos fundamentos da engenharia de
software para apoiar as atividades do desenvolvimento.
Isso tem como consequncia o crescente custo com
manuteno dos sistemas, retrabalho (em nvel de requisitos,
projeto, codificao, teste) causado por uma definio do
domnio do problema mal elaborada nas fases iniciais do
desenvolvimento.
14
Importncia dos Requisitos
1. Porque os requisitos so importantes?
15
Requisitos
Falta de cuidado com os requisitos pode levar a
construo de um sistema que resolve o problema errado;
No funciona como esperado;
Difcil para os usurios entenderem e utilizarem;
Alto custo.
16
Requisitos
17
Tipos Requisitos
Requisitos do usurio
Declaraes em linguagem natural e tambm em diagramas
sobre as funes que o sistema deve fornecer e as restries sob
as quais deve operar.
Requisitos do sistema
Um documento estruturado que estabelece detalhadamente as
funes e as restries de sistema.
Escrito como um contrato entre o cliente e o desenvolvedor do
software.
Especificao do software
Uma descrio detalhada do software que serve como base
para projeto e a implementao. Escrito para os
desenvolvedores.
18
Tipos Requisitos - Atores
19
Tipos Requisitos - Exemplo
20
Tipos Requisitos de Sistema
Requisitos funcionais
Declaraes de servios que o sistema deve fornecer, como o
sistema deve reagir a entradas especficas e como deve se
comportar em determinadas situaes.
Requisitos no funcionais
Restries sobre os servios ou as funes oferecidas pelo
sistema.
Requisitos de domnio
Requisitos que se originam do domnio da aplicao do sistema
e que refletem caractersticas desse domnio (Podem ser
requisitos funcionais e no funcionais).
21
Requisitos Funcionais
O que ?
Descrevem a funcionalidade ou os servios do sistema.
Dependem do tipo de software, das expectativas dos
usurios e do tipo de sistema que est sendo desenvolvido.
Requisitos funcionais do usurio so descritos de forma
bem geral, mas os requisitos funcionais de sistema
descrevem a funo de sistema detalhadamente.
22
Requisitos Funcionais: Exemplo
1. O usurio deve ser capaz de manipular arquivos no drive virtual
2. O usurio deve ser capaz de compartilhar arquivos e pastas
com outros usurios.
3. O administrador deve ser capaz de manipular usurios.
4. O administrador deve administrar a utilizao do disco virtual
pelos usurios.
23
Preciso dos requisitos funcionais
A especificao de requisitos funcionais deve ser completa
e consistente
Completeza
Todas as funes requeridas pelo usurio devem estar
definidas
Consistncia
No devem haver definies contraditrias de requisitos.
Problemas se originam da impreciso na especificao de
requisitos.
Requisitos ambguos podem ser interpretados de maneira
diferente pelos desenvolvedores e usurio.
24
Requisitos No Funcionais
Definem as propriedades de sistemas e restries, por ex:
confiabilidade, tempo de resposta e espao em disco.
Restries: capacidade dos dispositivos de E/S,
representaes de dados, etc.
Requisitos no funcionais dizem respeito ao sistema como
um todo. Alguns podem restringir o processo que utilizado
para desenvolver o sistema (ditar um sistema CASE
especfico, linguagem de programao ou mtodo de
desenvolvimento)
Podem ser mais crticos que requisitos funcionais. A falha
em atender um requisito no funcional de sistema pode
inutilizar o sistema.
25
Classificaes No Funcionais
Requisitos de produto
Requisitos que especificam o comportamento do produto.
Ex: velocidade de execuo, confiabilidade, portabilidade,
facilidade de uso, etc..
Requisitos organizacionais
Requisitos que so consequncia de polticas de
procedimentos nas organizaes do cliente e do
desenvolvedor. Ex: padres de processos que devem ser
utilizados, requisitos de implementao, etc.
Requisitos externos
Requisitos procedentes de fatores externos ao sistema e a
seu processo de desenvolvimento. Ex: requisitos de
interoperabilidade, requisitos legais e os requisitos ticos.
26
Tipos de Requisitos No Funcionais
27
Requisitos de Domnio
Refletem fundamentos da aplicao e podem ser novos
requisitos funcionais em si, podem restringir os requisitos
funcionais existentes, ou estabelecer como realizar clculos
especficos.
Se no forem satisfeitos, poder ser impossvel fazer o sistema
operar satisfatoriamente.
Exemplo:
Deve haver uma interface padro com o usurio para todos os
bancos de dados, que ter como base o padro Z 39.50
Principal problema com requisitos de domnio
Declaraes implcitas
Especialistas em um domnio podem deixar de fornecer
informaes em um requisito, simplesmente por acharem que
essas informaes so muito bvias.
28
Requisitos de Usurio
Devem descrever os requisitos funcionais e no funcionais de
modo compreensvel pelos usurios do sistema, que no tem
conhecimentos tcnicos detalhados.
Requisitos do usurio so definidos usando linguagem natural,
tabelas e diagramas.
29
Engenharia de requisitos um termo usado para descrever
as atividades relacionadas produo (levantamento,
registro, validao e verificao) e gerncia (controle de
mudanas, gerncia de configurao, rastreabilidade,
gerncia de qualidade dos requisitos) de requisitos.
30
Produo de Requisitos
A cada fase do ciclo de vida do software produzimos um
documento contendo uma representao distinta do
software a ser construdo.
Cada um desses documentos representa o software em um
determinado nvel de abstrao. A tendncia diminuirmos
o nvel de abstrao atravs da incluso de mais e mais
detalhes, at que, sua ltima representao seja o cdigo
fonte na linguagem escolhida.
Um dos artefatos produzidos no incio do processo de
desenvolvimento de software a sua especificao de
requisitos. Ele base para as demais atividades de
desenvolvimento e sua qualidade fundamental para o
sucesso do projeto.
31
Produo de Requisitos
Uma especificao de requisitos bem elaborada pr-
requisito para um software de qualidade, embora no seja
garantia disso.
Desta forma, durante a produo de requisitos devemos
possuir, alm das atividades essenciais de levantamento e
especificao, atividades relacionadas garantia da
qualidade.
Conheceremos as quatro atividades base relacionadas com
a produo de requisitos.
32
Levantamento de Requisitos
Esta atividade relaciona-se obteno dos requisitos do
software.
Para isto, analistas e engenheiros de software trabalham
com clientes e usurios finais para descobrir o problema a
ser resolvido, os servios do sistema, o desempenho
necessrio, restries de hardware e outras informaes.
Existem algumas tcnicas que apoiam as atividades de
levantamento de requisitos.
1. Entrevista
2. Prototipao
3. JAD (Joint Application Development)
33
Entrevista
Esta tcnica resume-se em conversas realizadas com o
usurio (entrevistado) para levantar os requisitos do
sistema a ser desenvolvido.
Podemos decompor esta tcnica nas seguintes atividades:
1. Ler material de suporte;
2. Estabelecer os objetivos da entrevista;
3. Decidir quem entrevistar;
4. Preparar o entrevistado;
5. Decidir os tipos de questes e a sua estrutura.
34
Entrevista
Uma entrevista pode ser estruturada de trs diferentes formas:
Estrutura em pirmide:
iniciamos as entrevistas com perguntas mais especificas sobre o
sistema e fechamos com perguntas mais genricas. Geralmente
utilizadas com usurios mais relutantes;
Estrutura em funil:
iniciamos as entrevistas com perguntas mais genricas sobre o sistema
e fechamos com perguntas mais especificas. Geralmente utilizadas com
usurios que tem uma relao mais afetiva com o assunto;
Estrutura em diamante:
esta estrutura combina as duas estruturas anteriores e utilizadas para
manter a usurio entrevistado interessado no assunto e para isto se
utiliza de perguntas variadas.
35
Prototipao
Prototipao uma verso inicial de um sistema para
experimentao.
Permite aos utilizadores identificar os pontos fortes e fracos
do sistema por ser algo concreto que pode ser criticado.
Temos dois tipos de prottipos:
Prottipos Throw-away:
ajudam o levantamento e desenvolvimento dos requisitos e
suportam os requisitos mais difceis de perceber;
Prottipos Evolutivos:
ajudam o desenvolvimento rpido de uma verso inicial do
sistema e suportam os requisitos bem definidos e
conhecidos.
36
JAD (Joint Application Development)
JAD uma tcnica que permite a interao entre pessoas que
necessitam tomar decises que afetem mltiplas reas de uma
organizao.
Esta tcnica envolve atividades de preparao para as reunies,
sesses de workshop com os participantes, agenda para as
reunies, participantes assumindo papeis de facilitador / condutor
e documentador alm de facilidades visuais, como a utilizao de
flipchart, quadro negro.
Esta tcnica deve ser utilizada nos casos onde existe a
necessidade de consenso entre diversos usurios, pois
possibilita a todos os envolvidos ter uma viso global do sistema,
ajudando a consolidar interesses de diversos usurios quanto ao
sistema a ser desenvolvido.
37
Problemas
A atividade de levantamento de requisitos no trivial.
Existe um conjunto grande e variado de fatores que a tornam
complexa, por exemplo:
1. Falta de conhecimento do usurio das suas reais
necessidades
2. Falta de conhecimento do desenvolvedor do domnio do
problema
3. Comunicao inadequada entre os desenvolvedores e
usurios
4. Dificuldade do usurio tomar decises
5. Complexidade crescente dos sistemas atuais.
38
Registro de Requisitos
Registro
Uma vez identificados e negociados, os requisitos devem
ser documentados para que possam servir de base para o
restante do processo de desenvolvimento.
Os requisitos so documentados em um nvel apropriado de
detalhe. Em geral produzido um documento de
especificao de requisitos, de forma que todos os
stakeholders possam entend-lo.
O registro dos requisitos num documento prprio facilita o
controle de alteraes de todos os envolvidos na
manuteno dos requisitos, bem como a gerao de
verses do documento e a facilidade de acesso por todos
os envolvidos.
39
Verificao de Requisitos
Verificao
Esta atividade examina a especificao do software, de
forma a assegurar que todos os requisitos foram definidos
sem ambigidades, inconsistncias ou omisses,
detectando e corrigindo possveis problemas ainda durante
a fase de definio dos requisitos.
Revises de artefatos de software tm se mostrado uma
abordagem eficiente e de baixo custo para encontrar
defeitos logo aps terem sido introduzidos, reduzindo o
retrabalho e melhorando a qualidade dos produtos.
No em vo que modelos de maturidade de processo de
software, como o CMMI e o MPS BR exigem a conduo de
revises.
40
Validao de Requisitos
Validao
A validao representa a atividade em que obtemos o
aceite do cliente sob determinado artefato.
No cenrio de engenharia de requisitos, esta atividade
significa aprovar junto ao cliente os requisitos que foram
especificados.
Embora aparentemente simples, esta atividade pode ser
bastante dificultada pelo cliente ou mesmo por um processo
de validao inadequado utilizado pela empresa.
41
Gerenciamento de Requisitos
Requisitos so por natureza volteis. Diversos fatores
contribuem para sua instabilidade ao longo do tempo.
Mudanas externas no ambiente (mudanas de legislao,
mudanas no mercado, mudana no posicionamento
estratgico da empresa), erros incorridos no processo de
requisitos, entre outros.
Todos esses fatores fazem com que seja necessrio alterar
os requisitos. Tais alteraes precisam ser conduzidas de
forma ordenada para que no se perca controle sobre o
prazo e o custo do desenvolvimento.
Denominamos a atividade de administrar os requisitos ao
longo do tempo de gerenciamento de requisitos.
42
Veremos a partir de agora algumas das atividades que devem
ser consideradas durante a gerncia dos requisitos:
1. Controle de Mudanas
2. Gerencia de Configurao
3. Rastreabilidade
4. Gerencia de Qualidade
43
Controle de Mudanas
Conforme foi citado anteriormente, os requisitos so
volteis e, portanto sofrem mudanas ao logo do tempo,
para conduzir estas mudanas recomenda-se preparo e
planejamento.
Uma das maneiras bastante utilizadas para organizar estas
mudanas a baseline de requisitos que nos permite
diferenciar o que era o requisito original, o que foi
introduzido e o que foi descartado.
Alm disto, interessante estabelecer um nico canal para
controle de mudanas, bem como utilizar um sistema para
este controle.
44
Gerencia de Configurao
Durante o ciclo de vida do desenvolvimento, o software
passa por uma srie de modificaes, desde a
especificao dos requisitos at a implantao do sistema.
A gerncia de configurao de software existe no intuito de
definir critrios que permitam realizar tais modificaes
mantendo-se a consistncia e a integridade do software
com as especificaes, minimizando problemas
decorrentes ao processo de desenvolvimento, atravs de
um controle sistemtico sobre as modificaes.
45
Rastreabilidade
No centro da atividade de gerenciamento de requisitos
est a rastreabilidade.
Esta definida como a habilidade de se acompanhar a
vida de um requisito em ambas as direes do processo
de software e durante todo o seu ciclo de vida.
Para implementar a rastreabilidade, usualmente
confeccionado em conjunto com a especificao de
requisitos um artefato chamado matriz de rastreabilidade,
que tem como objetivo mapear os rastros dos requisitos
descritos na especificao.
46
Gerencia de Qualidade
A gerncia de qualidade responsvel por manter uma
infra-estrutura necessria para atividades de verificao
que tornem possvel investigarmos a qualidade dos
requisitos que estamos definindo. Exemplo:
Correo: um documento de requisitos considerado
correto se todos os requisitos representam algo que deve
estar presente no sistema que est sendo desenvolvido,
ou seja, os requisitos reais do usurio devem coincidir com
os requisitos identificados.
Esta no uma tarefa trivial e parte de seu sucesso est
associada a uma boa atividade de validao dos
requisitos.
47
1 semestre de 2014
Aula 3
Artefatos de Requisitos
Principais Atores e Artefatos
49
Requisitos de Usurio
Requisitos de usurio so declaraes, em linguagem
natural e diagramas, sobre os servios que o sistema
oferece e as restries para a sua operao.
Escrito para os clientes.
Exemplos:
1. Mapeamento de processos
2. Documento de Viso
3. Estrutura Analtica de Projetos
50
Mapeamento de Processos
O Mapeamento de processos uma tcnica geral utilizada
por empresas para entender de forma clara e simples como
uma unidade de negcio est operando, representando
cada passo de operao dessa unidade em termos de
entradas, sadas e aes.
51
Documento de Viso
Documento de Viso
Este documento tem como objetivo fornecer uma viso
geral do sistema, abrangendo coleta, analise e definio
das necessidades e recursos necessrios aos envolvidos e
usurios finais.
As informaes contidas neste documento visam
estabelecer subsdios para a modelagem do sistema,
incluindo desde a definio de requisitos ao
desenvolvimento propriamente dito.
Os detalhes de como o sistema satisfar essas
necessidades so descritos no caso de uso e nas
especificaes suplementares.
52
Documento de Viso
Documento de Viso
O propsito expor as necessidades e funcionalidades
gerais do sistema.
Ser desenvolvido aps coleta e anlise dos requisitos
preliminares, que podem estar descritos no Documento de
Requisitos e no Documento de Regras de Negcio.
Seu foco est nas necessidades dos patrocinadores
(stakeholders) e no motivo da existncia destas
necessidades.
53
Documento de Viso
Documento de Viso
Estrutura de um documento de viso:
1. Escopo
2. Gestores
3. Levantamento de Necessidades
4. Classificao de Necessidades por Categoria
5. Funcionalidade do Produto
6. Integrao com outros Sistemas
7. Restries
54
Documento de Viso
Estrutura de um Documento de Viso
1. Escopo
Descreve aspectos e funes que devem fazer parte do
produto, incluindo projetos associados e qualquer coisa que
possa ser afetada por este projeto.
2. Gestores
Quem vai gerenciar e as funcionalidades que emergem a
partir desse gestor.
55
Documento de Viso
3. Levantamento de Necessidades
Problema
O que afeta
Impacto disso
Soluo
4. Classificao de Necessidades por Categoria
Crtico
Importante
til
56
Documento de Viso
5. Funcionalidade do Produto
Caractersticas funcionais levantadas com o objetivo de
satisfazer as necessidades identificadas anteriormente.
As funcionalidades devem estar ordenadas por prioridade,
conforme os critrios do prprio usurio.
A granularidade destas funcionalidades maior que a de
um caso de uso.
57
Documento de Viso
6. Integrao com outros Sistemas
Descreve de forma simples, ou atravs de um diagrama,
outros sistemas com os quais este sistema se relacione.
Caso no exista, no precisa existir esse tpico.
7. Restries
So descritos requisitos, tcnicos ou no, sem os quais o
sistema ser invivel, ou que limitem as alternativas de
soluo possveis.
58

Aula 2 - Mapeamento de Processos - Esw

Enviado por

Dados do documento

Descrição 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

Aula 2 - Mapeamento de Processos - Esw

Enviado por

Direitos autorais:

Formatos disponíveis

1 semestre de 2014

Você também pode gostar