08/02/2011
O que software?
Programas de computador e sua documentao respectiva, tais como modelos de anlise, manuais do usurio, etc. Produtos de software podem ser desenvolvidos para um cliente particular ou para o mercado em geral
Genricos: desenvolvidos para serem vendidos (usados) para uma variedade de clientes (p. ex. MS Office) Customizados: desenvolvidos para um cliente especfico, de acordo com uma especificao fornecida por ele
Um novo software pode ser criado a partir do zero, da configurao de software genrico ou do reuso de software existente
08/02/2011
08/02/2011
O que um PDS?
Conjunto de atividades com o objetivo de desenvolver ou evoluir um software Atividades genricas em todos os processos de desenvolvimento de software incluem
Especificao: o que o sistema deve fazer e as suas restries Desenvolvimento: produo do sistema de software Validao: verificao de que o software o que o cliente espera Evoluo: alterar o software em resposta a novas demandas dos clientes
Confiana
Um software confivel (confiabilidade, proteo, segurana) no deve causar danos fsicos ou econmicos no caso de falha no sistema
Eficincia
O software no deve desperdiar os recursos do sistema, como memria e processador
Usabilidade
O software deve ser usvel, sem um esforo excessivo, pelo tipo de usurio para o qual ele foi projetado Interface com o usurio e documentao adequados
08/02/2011
08/02/2011
Especificao de software
Processo para compreender e definir quais servios so necessrios e identificar as restries de operao e de desenvolvimento do software Processo de engenharia de requisitos
Estudo de viabilidade Levantamento e anlise de requisitos Especificao de requisitos Validao de requisitos
08/02/2011
08/02/2011
Desenvolvimento de software
Processo de converso de uma especificao de software em um software executvel Envolve processos de projeto e implementao Projeto de software
Projetar uma estrutura de software que realiza a especificao
Desenvolvimento de software
Atividades do projeto de software
Projeto arquitetural
Os subsistemas constituintes do software e seus relacionamentos so identificados e documentados
Especificao abstrata
Para cada subsistema, so produzidas uma especificao abstrata dos servios e das restries sob as quais deve operar
Implementao
Traduzir esta estrutura para um programa executvel
Projeto da interface
Para cada subsistema, projetada e documentada a interface com outros subsistemas
Projeto de componentes
Os servios e as interfaces de cada subsistema so projetados
08/02/2011
08/02/2011
Desenvolvimento de software
Atividades do projeto de software (cont.)
Projeto da estrutura de dados
As estruturas de dados usadas em cada subsistema so projetadas detalhadamente
Validao de software
Verificao e validao procura mostrar que um sistema est conforme sua especificao e que alcana os requisitos do cliente Envolve processos de inspeo (verificao esttica) e testes (verificao dinmica) Estgios do processo de teste
Teste de unidade (componente) Teste de integrao (sistema) Teste de aceitao
08/02/2011
08/02/2011
Evoluo de software
Software inerentemente flexvel e pode sofrer mudanas
Com as mudanas de requisitos devido mudanas das circunstncias do negcio, o software que d suporte ao negcio tambm tem que evoluir e mudar
Tipos de manuteno
Reparar defeitos Adaptar software Adicionar / modificar funcionalidades
Requisitos de Software
Processo de manuteno
Solicitao de mudana Anlise de impacto Planejamento de verso Implementao de mudana Liberao do sistema
08/02/2011
08/02/2011
O que um requisito?
Um requisitos uma descrio de
Servios (funcionalidades) Restries (de operao e de desenvolvimento)
A descrio de um requisitos pode variar variar de uma descrio abstrata (de alto-nvel) de um servio ou de uma restrio do sistema at uma especificao matemtica detalhada
Quanto mais tarde no processo de desenvolvimento um defeito for detectado, maior ser o custo para consert-lo
Estgio do PDS e custo relativo de conserto de um defeito
Requisitos 1 Anlise e projeto 5 Codificao 10 Teste de aceitao 50 Manuteno 200
08/02/2011
08/02/2011
Nveis de abstrao
O que o cliente quer / o que o sistema deve fazer
Nveis de requisitos
Requisitos de usurio (nvel: problema)
Define os servios que o sistema deve oferecer e as suas restries operacionais
Necessidades
Viso
Problema Soluo
Mostra descries detalhadas das funcionalidades do sistema Define o que deve ser projetado/implementado e deve fazer parte do contrato
Especificao Detalhada
08/02/2011
08/02/2011
Requisitos no-funcionais
So propriedades ou qualidades que o produto deve possuir Em sua maioria, no expressam nenhuma funo a ser realizada pelo software, mas sim necessidades e restries que o mesmo deve satisfazer
08/02/2011
08/02/2011
Requisitos organizacionais
Requisitos que so conseqncia de polticas ou procedimentos organizacionais, por exemplo, padres utilizados e modo de implementao
Requisito organizacional
O processo de desenvolvimento do sistema e os documentos a serem entregues devem estar conformes ao modelo X
Requisito externo
O sistema no dever compartilhar informaes pessoais dos clientes a no ser seu nome e seu nmero de referncia para os operadores do sistema
Requisitos externos
Requisitos que vm de fatores que so externos ao sistema e seu processo de desenvolvimento, por exemplo, requisitos de interoperabilidade e requisitos legais
08/02/2011
08/02/2011
Consistentes
No deve haver conflitos ou contradies nas descries das funcionalidades do sistema
08/02/2011
08/02/2011
Refinamento de requisitos
Refinamento de requisitos funcionais
Definir
Cada entrada e sada Cada validao Cada transformao Os comportamento normais e alternativos Os comportamentos em cada exceo
Refinamento de requisitos
Refinamento de requisitos no-funcionais
Requisitos no-funcionais podem ser difceis de se refinar precisamente e, conforme dito anteriormente, requisitos imprecisos so difceis de se verificar
08/02/2011
08/02/2011
Refinamento de requisitos
Exemplo de refinamento de requisito no-funcional
Um objetivo do sistema
O sistema deve ser fcil de ser usado por controladores experientes e deve ser organizado de forma a minimizar os erros dos usurios Requisito no-funcional de usabilidade
Requisitos e o desenvolvimento
Requisitos devem mostrar o que o sistema deve fazer e o projeto deve mostrar como o sistema deve fazer Alguns detalhes
A arquitetura do software deve ser diretamente derivada de seus requisitos O software pode ter que inter-operar com outros sistemas, isto cria novos requisitos que tero impacto no projeto
08/02/2011
08/02/2011
Documentando requisitos
Requisitos podem ser documentados de diversas maneiras As maneiras mais usuais de se documentar requisitos so
Linguagem natural Formulrios Modelagem grfica
Documentando requisitos
Linguagem natural
Faz uso de texto em lngua corrente para descrever os requisitos de sistema Problemas
Ambigidade
Quem escreve e quem l o documento podem interpret-los de formas diferentes
Muita flexibilidade
Uma mesma coisa pode ser descrita de diversas formas
Falta de modularizao
A estrutura da linguagem natural no a melhor para se descrever requisitos
08/02/2011
08/02/2011
Documentando requisitos
Formulrios
Faz uso de linguagem natural estruturada para descrever os requisitos de sistema Campos usuais
Definio da funo ou entidade Descrio das entradas e de onde elas vm Descrio das sadas e para onde elas vo Indicao de que outras entidades so necessrias Pr e ps-condies (onde aplicveis) Os efeitos colaterais da funo (se existirem)
Documentando requisitos
Modelagem grfica
Modelos grficos so interessantes quando se precisa mostrar mudanas de estado ou seqncia de aes Exemplos
Diagrama de Fluxo de Dados Modelo de Casos de Uso
08/02/2011
08/02/2011
08/02/2011
08/02/2011
Modelo do processo de ER
A ER um processo iterativo
Rejeitada
Clientes
Desenvolvedores
08/02/2011
08/02/2011
Estudo de viabilidade
Um estudo de viabilidade deve decidir se vale a pena desenvolver o sistema Um estudo focado que verifica
Se o sistema contribui para os objetivos organizacionais Se o sistema pode ser desenvolvido com a tecnologia e o oramento disponveis Se o sistema pode ser integrado com outros sistemas em funcionamento
Estudo de viabilidade
Fazendo um estudo de viabilidade
Baseado na coleta e avaliao de informao e no levantamento e anlise de riscos do projeto Procurar respostas com as pessoas da organizao para perguntas do tipo
Quais so os problemas existentes? De que forma o/um sistema ajudaria a resolver este problema? Que facilidades devem ser oferecidas pelo sistema proposto? Qual a tecnologia e as competncias necessrias para desenvolver o sistema? E se o sistema no for desenvolvido?
08/02/2011
08/02/2011
Priorizao e negociao
Priorizar requisitos e resolver conflitos existentes
08/02/2011
08/02/2011
08/02/2011
08/02/2011
Providenciar recursos
Agendar data/horrio e durao Agendar local apropriado com os recursos necessrios
Registro
No tente anotar todos os detalhes durante a entrevista. Use um gravador, se possvel, ou o apoio de outro profissional Registre definies, pendncias e atividades a serem realizadas
Encerramento
Abra um canal para comunicao posterior com os entrevistados (nome telefone email) Conclua a reunio, informando os prximos passos
Notificar os participantes
08/02/2011
08/02/2011
08/02/2011
08/02/2011
Na segunda etapa, debate-se com o grupo para ir refinando as idias apresentadas anteriormente
08/02/2011
08/02/2011
08/02/2011
08/02/2011
08/02/2011
08/02/2011
Fases do JAD
Definio do projeto JAD Pesquisa Preparao Sesso JAD Documento final
Fase de Pesquisa
Familiarizao com as reas de negcio e com sistemas Recolhimento de informaes preliminares Preparao da agenda da sesso JAD
Fase de Preparao
Elaborao do documento de trabalho Treinamento do documentador e estabelecimento do protocolo de comunicao Preparao das facilidades visuais e da sala da reunio
08/02/2011
08/02/2011
Viso geral do negcio Discutir as premissas coletadas Identificar e discutir os tpicos do documento de trabalho, procurando um consenso nas decises
Para cada tpico a ser validado de cada rodada, o facilitador Apresenta o tpico Transfere a palavra a cada um dos participantes da sesso, solicitando que se manifeste sobre o tpico
08/02/2011
08/02/2011
Especificao de requisitos
Documentar os requisitos levantados, analisados e priorizados Usar documento padronizado pelo processo
Serve de comunicao entre a equipe de desenvolvimento e os clientes DFDs, Modelos de Casos de Uso, etc.
A anlise distribui os requisitos em categorias, explora as relaes entre eles, e classifica a importncia de cada um dos requisitos (priorizao)
08/02/2011
08/02/2011
10
Especificao de requisitos
Especificaes suplementares
Regras de negcio Arquitetura Padro de interfaces
Usurio, hardware, software e comunicao
Validao de requisitos
Se preocupa em demonstrar que os requisitos definem o sistema que o cliente realmente quer
Estamos construindo o produto correto? Estamos construindo o produto da forma correta?
A especificao examinada de forma a tentar assegurar que os requisitos foram definidos sem ambigidades, inconsistncias ou omisses, e que todos os defeitos foram detectados e corrigidos Inspeo e utilizao de checklists
08/02/2011
08/02/2011
Validao de requisitos
Deve-se validar os requisitos quanto a
Validade
O sistema oferece as funes que melhor atendem s necessidades dos usurios?
Validao de requisitos
Deve-se validar os requisitos quanto a (cont.)
Verificao
O requisito realisticamente testvel?
Compreensibilidade
O requisito foi corretamente entendido?
Consistncia
Existem requisitos conflitantes?
Rastreabilidade
A origem do requisito est claramente definida?
Completude
Todas as funes requeridas pelo cliente esto includas?
Adaptabilidade
Um requisito pode mudar sem afetar outros requisitos?
Realismo
Os requisitos podem ser implementados com as habilidades e o oramento disponveis?
08/02/2011
08/02/2011
Validao de requisitos
Tcnicas para validao de requisitos Reviso (inspeo) de requisitos
Anlise sistemtica (manual) dos requisitos
Gerncia de requisitos
Define uma abordagem sistemtica para levantar, organizar e documentar as modificaes nos requisitos executada em paralelo durante todo o processo de desenvolvimento Captura de informaes de apoio gerncia do projeto
Importncia Risco Release previsto ...
Desenvolvimento de prottipos
Usar um modelo executvel do sistema para checar seus requisitos
08/02/2011
08/02/2011
11
Gerncia de requisitos
Durante o processo de engenharia de requisitos, deve-se planejar Identificao dos requisitos
Como os requisitos so individualmente identificados
Gerncia de requisitos
Rastreabilidade
A rastreabilidade se preocupa com o relacionamento entre os requisitos, suas fontes e o projeto do sistema Rastreabilidade da fonte
Ligaes entre os requisitos e os interessados que os propuseram
Poltica de rastreabilidade
A quantidade de informao sobre os requisitos que deve ser mantida
Rastreabilidade do projeto
Ligaes entre os requisitos e o projeto/implementao do sistema
08/02/2011
08/02/2011
Gerncia de requisitos
Processo de gerncia de mudanas
Deve ser aplicada a todas as mudanas nos requisitos Estgios principais
Anlise do problema
Discutir o problema com o requisito e propor a mudana
Implementao da mudana
Modificar o documento de requisitos e os demais documentos relacionados
08/02/2011
08/02/2011
12