Visão geral

Prévia do material em texto

Visão geral
	
	Apresentação da disciplina:
	
	A disciplina de Processos de Negócio e Software tem a finalidade de proporcionar aos alunos a compreensão de Processos, engenharia de software e os modelos de processos existentes, engenharia de requisitos, gerenciamento de projetos, bem como posicionar o papel do engenheiro de software dentro de uma organização desenvolvedora e os aspectos éticos que devem ser seguidos.
	
 
	Objetivos:
	
	· Proporcionar fontes de estudo que possam contribuir para o conhecimento de processos de negócio e software, engenharia de software, engenharia de requisitos e gerenciamento de projetos;
· Auxiliar na compreensão da Qualidade tanto no Processo de Desenvolvimento de Software quanto no Produto.
· Oportunizar atividades com ferramentas Case, onde o aluno desenvolva habilidades específicas trabalhadas de acordo com o conteúdo ministrado.
	
	Conteúdo Programático:
	
	 
	
	Metodologia:
	
	
	Os conteúdos programáticos ofertados nessa disciplina serão desenvolvidos por meio das Teleaulas de forma expositiva e interativa (chat – tira dúvidas em tempo real), Aula Atividade por Chat para aprofundamento e reflexão e Web aulas que estarão disponíveis no Ambiente Colaborar, compostas de conteúdos de aprofundamento, reflexão e atividades de aplicação dos conteúdos e avaliação. Serão também realizadas atividades de acompanhamento tutorial, participação em Fórum, atividades práticas e estudos independentes (autoestudo) além do Material didático da disciplina.
	
	
 
	Avaliação Prevista:
	
	
	O sistema de avaliação da disciplina compreende em assistir a teleaula, participação no fórum, produções textuais interdisciplinares (Portfólio), realização de avaliações virtuais e avaliação presencial embasada no material didático, teleaulas, web aula e material complementar.
	
	 
	Critérios para Participação dos Alunos no Fórum:
	
	
	Quando houver fórum de discussão o aluno será avaliado quanto ao conteúdo de sua postagem, onde deverá comentar o tópico apresentando respostas completas e com nível crítico de avaliação pertinente ao nível de pós-graduação. Textos apenas concordando ou discordando de comentários de outros participantes do fórum sem a devida justificativa ou complementação não acrescentam em nada ao debate da disciplina, sendo assim, devem ser evitados. Os textos devem sempre vir acompanhados das justificativas para a opinião do discente sobre o conteúdo discutido, para que assim, possamos dar continuidade ao debate em nível adequado. Além disso, podem ser utilizados citações de artigos, livros e outros recursos que fundamentem a opinião ou deem sustentação a sua posição crítica sobre o assunto. Deve ser respeitado o tópico principal do fórum, evitando debates que não tem relação com o tema selecionado pelo professor.
	
  ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
WEB AULA 1
Unidade 1 – Processos de Negócio – Conceitos
 
Apresentação do professor
Seja bem-vindo à nossa primeira web aula da Unidade I!!!
Eu sou a professora Polyanna e estarei junto com vocês no desenvolvimento da disciplina de Processos de Negócio e Software.
Assim como você, eu também escolhi a área de Tecnologia em Análise e Desenvolvimento de Sistemas, visto que sou bacharel em Sistemas de Informação e pós-graduada em Engenharia de SW com UML. Profissionalmente, atuo como Gerente de Projeto numa empresa que desenvolve software para provedores de Internet, presto serviço de Análise de Negócio e Sistemas para uma Clínica Médica e sou docente nesta instituição.
Vamos para o conteúdo da nossa web aula?
Caros alunos, antes de irmos direto ao conteúdo “Processos de Negócio”, é importante saber que a palavra “Processo” pode nos remeter a situações corriqueiras de nossa vida, então vamos definir processo.
A engenharia de software, segundo Sommerville (2011), é um conjunto de atividades relacionadas que levam à produção de produto de software.
Na administração de empresas, um processo é o conjunto de atividades realizadas na geração de resultados para o cliente, desde o início do pedido até a entrega do produto.
Segundo o PMBOK (PMI, 2001), é um conjunto de ações e atividades inter-relacionadas que são executadas para alcançar um objetivo. Cada processo é caracterizado por suas entradas, as ferramentas e as técnicas que podem ser aplicadas e as saídas resultantes. Vejamos a figura 1 abaixo.
Na gestão de processos negócio (BPM), processo é uma sequência de tarefas ou atividades que, ao serem executadas, transformam insumos em um resultado com valor agregado.
Agora, “trocando em miúdos”, vamos imaginar que você deseja fazer uma bicicleta, qual seria o processo?
 
· Entrada (insumos): os pneus, as rodas, as porcas, parafusos, correntes, etc.
· Atividades (processamento): montagem do pedal, a inserção das rodas e o ajuste das engrenagens, etc.
· Saídas (resultado – Produto final): Bicicleta montada.
 
Esse é um simples exemplo, mas podemos falar em: Processo para “Implantação de um sistema de software”, “Criação de um site”, “Abertura de uma conta bancária”, “Criação de uma conta numa rede social”, “Fazermos um Bolo”, “Trocarmos um pneu”, “Formatarmos uma máquina”, “Tirar carteira de motorista” e etc.
Veja abaixo um “Processo de Entrega” de um produto onde a compra foi online.
	Agora é sua vez, tente imaginar um processo do seu dia a dia e comente no Fórum da disciplina para discurtimos.
Noções sobre Processos de Negócio
Segundo Harrington (1997), um processo de negócio é um conjunto de atividades lógicas, relacionadas e sequenciais que, a partir de uma entrada de um fornecedor, agrega-lhe valor e produz uma saída para um cliente.
Dentro da área de processos, quando falamos em Gestão de Processos de Negócios, utilizamos o termo BPM (Business Process Management), que se trata de um modelo para apoiar as organizações a criar e aperfeiçoar seus processos de negócio em tempo real, baseados em tecnologia, com foco na melhoria contínua de processos e, consequentemente, na satisfação dos clientes quanto à melhor qualidade dos produtos, agilidade de entrega de produtos e serviços baseado nas necessidades do mercado.
Segundo CBOK (2013), BPM é uma abordagem disciplinar para identificar, desenhar, executar, documentar, medir, monitorar, controlar e melhorar processos de negócio, automatizados ou não, para alcançar resultados consistentes e alinhados com os objetivos estratégicos da organização.
Para KROENKE (2012), Processos de Negócio trata-se de uma rede de atividades, funções, recursos, repositórios e fluxos de dados que interagem para executar uma função de negócios, onde:
 
· Atividades: São grupos de tarefas correlatadas que recebem dados e informações, e processam esses fatores para produzir resultados.
· Decisões: Uma questão que pode ser respondida como “Sim” ou “Não”.
· Funções: Conjuntos de Procedimentos.
· Recursos: Físicos, envolve a infraestrutura necessária para a realização de uma determinada função. Humanos, são pessoas necessárias a desempenhar determinada função.
· Repositórios: é o local de armazenamento dos registros das empresas.
· Fluxo de Dados: É a movimentação de dados de uma atividade para outra.
Com o uso do BPM, as empresas têm conseguido entender sua estrutura organizacional a partir da visão de seus processos relacionados e trabalhando de forma integrada, deixando de lado a antiga visão departamental. E para as organizações se manterem competitivas no mercado, é necessário constante revisão destes processos e a sua divulgação. Vejamos na figura 3 abaixo um processo de negócio modelado BPMN (Notação de Gestão de Processos de Negócio), utilizando a ferramenta Bizagi e, na figura 4, utilizando a ferramenta Astah.
O diagrama abaixo da figura 3 foi criado usando a UML (linguagem de modelagem unificada), que abordaremos no próximo semestre.  Para saber mais sobre UML, Clique aqui.
 
	Para saber mais sobre Modelagem de Processo com as práticas BPM, acesse aqui: http://blog.iprocess.com.br/tag/modelagem-de-processos/
 
 
 
	Links importantes:
http://www.efagundes.com/tecnologias/Gestao_de_processos_de_negocios.htmhttp://www.efagundes.com/tecnologias/Gestao_de_processos_de_negocios.htm#sthash.UGLkRacf.dpuf
http://docs.kde.org/stable/pt_BR/kdesdk/umbrello/uml-basics.html
WEB AULA 2
Unidade 1 – Profissional de Software
 
O maior desafio hoje em empresas desenvolvedoras de software está no fato de que os profissionais ainda não implementam, em sua grande parte, ações características do Engenheiro de Software. Nesta web aula, primeiramente discutiremos aspectos básico deste profissional, estudando o desenvolvimento profissional e também os aspectos éticos na engenharia de Software.
O desenvolvimento profissional de software está ligado aos inúmeros usuários que escrevem os programas, podendo ser pessoas envolvidas com negócios que os escrevem para simplificar seu dia-a-dia, ou engenheiros e cientistas para processar seus dados experimentais, aqueles que escrevem como hobby, apenas por interesse próprio e diversão, e aqueles que desenvolvem profissionalmente, cujo software tem um propósito específico de negócio ou para inclusão de outros dispositivos, etc.
Sempre que tratamos de software, algumas perguntas sempre surgem, tais como:
· O que é software?
· Quais os atributos de um bom software?
· O que é engenharia de software?
· Quais as principais atividades de engenharia de software?
· Qual a diferença entre engenharia de software e ciência da computação?
· Qual a diferença entre engenharia de software e engenharia de sistemas?
· Quais são os principais desafios da engenharia de software?
· Quais são os custos da engenharia de software?
· Quais são as melhores técnicas e métodos de engenharia de software?
· Quais diferenças foram feitas pela internet na engenharia de software?
 
 
	Dica:
A resposta às perguntas acima se encontram no livro Engenharia de Software, 9ª edição, do autor Ian Sommerville, disponível na biblioteca digital.
 
O software profissional inclui técnicas para especificação, projeto, implementação e implantação que geralmente não são relevantes ao desenvolvedor pessoal.
Comumente, as pessoas associam um software como um programa de computador qualquer, porém, a engenharia de software não trata apenas do programa em si, mas de toda a documentação associada a fazer este programa funcionar corretamente.
Outra diferença entre o desenvolvedor profissional e o amador é que o amador escreve um programa para ele mesmo utilizar, não se preocupando em escrever um manual do programa, documentação, etc., enquanto o desenvolvedor profissional, que desenvolve um software para outras pessoas usarem, necessita fornecer informações adicionais, assim como o código do programa.
Existem dois tipos e produtos de software:
· Produtos Genéricos:
Ex: Ferramentas de banco de dados, processadores de textos, compactadores de arquivos, pacotes gráficos, sistemas de contabilidade, sistemas comerciais, etc.
· Produtos sob Encomenda
Ex: Sistemas de controle de dispositivos eletrônicos, sistemas especializado para apoio a determinado negócio, sistemas de controle rodoviário, etc.
A diferença entre esses tipos de software é que, no genérico, a empresa que desenvolve controla sua especificação, já o sob encomenda, a especificação é controlada pela empresa que está adquirindo o software.
Quando tratamos da qualidade do software profissional, devemos nos atentar aos seguintes atributos necessários a um bom software:
· Manutenibilidade, ou seja, a forma na qual o software possa evoluir para atender às necessidades dos clientes.
· Confiança e proteção, ou seja, um software não deve causar prejuízos físicos ou econômicos no caso de falhas do sistema.
· Eficiência, isto é, o software não deve desperdiçar recursos do sistema.
· Aceitabilidade.
Portanto, o software deve ser compreensível, usável e compatível com os outros sistemas conectados a ele.
 
Ética na Engenharia de Software
O desenvolvimento de software envolve grande responsabilidade, pois não é apenas aplicar habilidades técnicas, mas sim um conjunto de atividades sociais e legais, o que muitas vezes limita a liberdade das pessoas que trabalham nesta área. Desta forma, o engenheiro de software deve se comportar de forma ética e moralmente responsável se deseja ser respeitado como um engenheiro profissional.
Manter um padrão de honestidade e integridade é fundamental para um profissional de sistemas, visto que não se deve usar suas habilidades e conhecimentos para agir de forma desonesta ou de maneira na qual possa denegrir a profissão do engenheiro de software. Em algumas áreas de atuação do engenheiro de software, nas quais os padrões de comportamento não são limitados pelas leis, há uma tênue noção de responsabilidade profissional na qual envolve:
· Confidencialidade: devemos respeitar a confidencialidade de informações dos clientes, independentemente de ter sido assinado ou não um contrato de confidencialidade
· Propriedade Intelectual: devemos conhecer as leis locais a respeito do assunto, tais como patentes e copyright, sempre tendo cuidado de proteger a propriedade intelectual dos empregados e clientes.
· Competência: não devemos aceitar, conscientemente, um trabalho fora de nossa competência profissional.
· Mau uso do computador: o profissional de software não deve usar de suas habilidade técnicas para fazer mau uso de computadores de outras pessoas, podendo variar desde o uso dos computadores da empresa para acesso a redes sociais, jogos, sites não liberados até algo mais sério, como a disseminação de vírus ou outros malwares.
Sommerville (2011 p. 9-10) mostra no quadro abaixo o código de ética e praticas profissionais da ACM/IEEE 1999 de forma reduzida.
	Código de ética e práticas profissionais da engenharia de software
Força-tarefa conjunta da ACM/IEEE para ética e práticas profissionais de engenharia de software
Prefácio
A versão curta do código resume aspirações a um nível alto da abstração; as cláusulas que são incluídas na versão cheia dão exemplos e detalhes de como estas aspirações mudam o modo que nós agimos como software que cria os profissionais. Sem as aspirações, os detalhes podem se tornar legalísticos e tediosos; sem os detalhes, as aspirações podem se tornar soando altos, mas podem esvaziar; junto, as aspirações e os detalhes formam um código aderente.
Engenheiros de software começam a fazer a análise, especificação, designer, desenvolvimento, prova e manutenção de software. Conforme o seu compromisso para a saúde, segurança e bem-estar do público, os engenheiros de software aderirão aos seguintes princípios:
· Público: Engenheiros de software agirão constantemente com o interesse público;
· Cliente e Empregador: Engenheiros de software agirão até certo ponto, isto é, com interesse do seu cliente e empregador de acordo com o interesse público;
· Produto: Os engenheiros de softwre assegurarão que os seus produtos e suas modificações estão relacionados e satisfazem aos padrões profissionais de mais alto nível possível;
· Julgamento: Engenheiros de software manterão integridade e independência no seu julgamento profissional;
· Gerenciamento: Engenheiros de Software precisam lidar com os gerentes e líderes que atuam no projeto, promovendo assim uma aproximação ética à administração do desenvolvimento de software e sua manutenção
· Profissão: Engenheiros de software melhoraram a reputação da profissão da área de Tecnologia da Informação, indo de acordo com o interesse público;
· Colegas: Engenheiros de software devem ser justos e encorajar seus colegas;
· Si Próprio: Os engenheiros de software estão sempre aprendendo, por meio de experiências vitalícias relativas à prática de sua profissão (SOMMERVILLE, 2011, p. 10-11).
 
A ética e a responsabilidade profissional estão ficando cada dia mais importantes à medida que os sistemas que fazem uso intensivo de software se infiltram em cada aspecto do trabalho e da vida cotidiana.
 
Em resumo
 
· A Engenharia de Software é uma disciplina de engenharia que se preocupa com todos os aspectos de produção de software.
· Produtos de software consistem em programas desenvolvidos e documentação associada. Atributosde produto essenciais são manuteníveis, confiáveis, eficientes e usáveis.
· O processo de software consiste em atividades que são envolvidas em produtos de software em desenvolvimento. Atividades básicas são especificações de software, desenvolvimento, validação e evolução.          
· Métodos são modos organizados de produzir software. Eles incluem sugestões para o processo a ser seguido, as anotações a serem usadas, regras que governam as descrições de sistema que são produzidas e projetam diretrizes.
· Ferramentas CASE são sistemas de software que são projetados para apoiar atividades rotineiras no processamento de software, como editar desígnio esquematizado, conferir a consistência de diagramas e rastrear e manter testes de programa que foram feitos.
· Engenheiros de software têm responsabilidades pertinentes à profissão de engenharia e à sociedade, não deveriam simplesmente ser interessados apenas em assuntos técnicos.
· Sociedades de profissionais publicam códigos de conduta que definem os padrões de comportamentos esperados dos seus sócios.
WEBAULA 1
Unidade 2 – Engenharia de Requisitos
 
Na Engenharia de Software, temos uma especialidade que é a Engenharia de Requisitos, sendo um de seus objetivos melhorar a modelagem de sistemas, possibilitando maior entendimento de suas características antes da implementação. Portanto, nesta aula abordaremos conceitos e técnicas aplicados a estes requisitos.
Caro aluno, nesta Web aula abordaremos assuntos relacionados ao tema Engenharia de Software, onde iremos explorar os Processos de Engenharia de Requisitos com suas principais características e funcionalidades. Darei algumas sugestões de leituras e vídeos para que possamos explorar mais a fundo o tema tratado.
 
Conceitos de Requisitos
Antes do assunto direto, vamos assistir algumas curiosidades em relação à Evolução do Computador por meio dos links:
· História do computador em minutos
 
· A interface Homem-computador
O motivo pelo qual apresentamos as visualizações por meio dos vídeos é para identificar a importância e a agilidade das inovações no meio computacional.
Dessa forma, podemos ter noção de alguns aspectos que destacam a necessidade do entendimento dos princípios de engenharia, para que possamos ter softwares que sejam eficientes e confiáveis.
Agora, voltamos para o assunto em destaque desta web aula, que são os Processos de Engenharia de Requisitos. Esses processos são utilizados para descobrir, analisar e validar os requisitos dos sistemas. Suas principais atividades são:
· Estudo de viabilidade;
· Elicitação (levantamento) e análise de requisitos;
· Especificação e documentação de requisitos;
· Validação de requisitos.
Processo de Engenharia de Requisitos
 
Para aprofundar o seu conhecimento:
Assista ao vídeo:
· Engenharia de Requisitos
 
Estudo de viabilidade
O estudo de viabilidade consiste num estudo preliminar de requisitos de negócios, no qual é decidido se vale a pena desenvolver o sistema proposto. Um estudo breve verifica se:
· sistema contribui para os objetivos da organização;
· sistema pode ser implementado com a tecnologia atual e dentro do orçamento;
· sistema pode ser integrado com outros sistemas em operação. (SOMMERVILLE, 2007, p. 97).
 
Implementação do estudo de viabilidade
A realização do estudo de viabilidade envolve a avaliação de informações, coleta de dados e a elaboração de um relatório. Para auxiliar na implementação, alguns questionamentos podem ser levantados às pessoas na organização, tais como:
-   O que aconteceria se o sistema não fosse implementado?
-   Quais são os problemas com os processos atuais?
-   Como o sistema proposto irá ajudar?
-   Pode haver troca de informações entre outros sistemas e o sistema proposto?
-   Será necessário nova tecnologia? Quais habilidades?
-   O que precisa e o que não precisa ser compatível com o sistema?
Durante esta fase, podemos consultar os engenheiros de software, especialistas em tecnologia e os usuários finais para coletarmos as informações. Geralmente, leva-se de 02 (duas) a 03 (três) semanas para concluir as atividades.
 
Elicitação e análise de requisitos
Nesta atividade, os engenheiros trabalham em conjunto com os usuários finais do sistema com o intuito de entender o domínio da aplicação. Para tal, envolvem-se várias pessoas da organização, que são denominadas stakeholders.
Os membros da equipe técnica trabalham com o cliente e os usuários para descobrir mais informações sobre o domínio da aplicação, serviços do novo sistema, desempenho e as restrições operacionais.
O termo Stakeholder é aplicado a qualquer pessoa que terá influência direta ou indireta sobre os requisitos do sistema, podendo ser usuários finais, pessoal de uma organização que venha a ser afetado pelo sistema, engenheiros envolvidos no desenvolvimento ou manutenção do sistema (e/ou outros sistemas relacionados), gerentes de negócios, especialistas no domínio da aplicação e até representantes de sindicatos.
Problemas com a análise de requisitos
Durante o processo de elicitação e análise dos requisitos, encontramos alguns problemas para realizar a atividade, pois:
-  Pessoas diferentes podem ter requisitos conflitantes;
-  Pessoas expressam os requisitos usando termos próprios;
-  Fatores políticos podem influenciar os requisitos do sistema;
-  Os requisitos se alteram durante o processo de análise, pois o ambiente econômico e de negócios é dinâmico.
 
Processo de elicitação e análise de requisitos
Podemos verificar que cada organização terá a sua própria versão de um modelo para a obtenção e análise de requisitos, dependendo de fatores locais, nível de conhecimento da equipe, tipos do sistema a ser desenvolvido e os padrões dos usuários.
As atividades do processo são:
-  Obtenção de requisitos – um processo que visa coletar requisitos, em que os requisitos de domínio também são descobertos durante esta atividade.
-  Classificação e organização de requisitos – envolve a coleta de requisitos não estruturados, agrupando-os e organizando-os em conjuntos coerentes.
-  Priorização e negociação de requisitos – atividade relacionada à priorização de requisitos, devido a requisitos conflitantes (quando há vários stakeholders atuando), à procura e à resolução de conflitos por meio de negociações.
-  Documentação de requisitos – são documentados e colocados na próxima volta da espiral, podendo ser produzidos documentos de requisitos formais ou informais.
 
Especificação e documentação de requisitos
A especificação de requisitos é uma etapa essencial do processo de desenvolvimento de software, que compreende uma definição completa do comportamento externo de software do sistema ou parte do sistema.
 
Requisitos do usuário
São declarações, em linguagem natural e diagramas, sobre os serviços que o sistema oferece e as restrições para a sua operação. São escritos para os clientes.
 
Requisitos do sistema
Estabelecem detalhadamente as funções e restrições do sistema. O documento de requisitos, chamado de especificação funcional, pode servir como um contrato entre cliente e desenvolvedor.
 
Especificação de software
Trata-se de uma especificação abstrata e precisa do software, indicando o que ele deve fazer (sem dizer como), que serve de base para o design e implementação. Ela acrescenta mais detalhes à especificação funcional e é escrita para a equipe de desenvolvimento.
       Ao descrever os requisitos, necessitamos nos atentar às seguintes situações, pois:
· A especificação dos requisitos deve ser completa (deve descrever tudo o que é necessário), consistente (não deve haver conflitos e contradições) e não ambígua (não deve levar a interpretações diferentes por desenvolvedores e usuários).
· É difícil de ser atingida, considerando que existem diferentes tipos de requisitos envolvidos.
· Depende da precisão da linguagem utilizada, visto que a linguagem natural, informal, é mais apropriada para os requisitos do usuário e do sistema, já as linguagens gráficas, semiformais, são apropriadas para os requisitos do sistema e do software, e as linguagens formaissão mais apropriadas para uma especificação formal de software em métodos formais.
Os requisitos de software são frequentemente classificados como requisitos funcionais e não-funcionais:
 
Requisitos funcionais
São declarações de serviços que o sistema deve fornecer, como ele deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações, sendo que, em muitas vezes, também podem explicar como o sistema deve ou não fazer.
Exemplo:
· "o software deve possibilitar o cálculo dos gastos diários, semanais, mensais e anuais com pessoal".
· "o software deve emitir relatórios de compras a cada quinze dias".
· "os usuários devem poder obter o número de aprovações, reprovações e trancamentos em todas as disciplinas por um determinado período de tempo".
 
Requisitos não-funcionais
São restrições aos serviços ou funções oferecidas pelo sistema, que incluem restrições de tempo, no processo de desenvolvimento e também restrições impostas por normas/leis. Os requisitos não-funcionais, muitas vezes, aplicam-se ao sistema como um todo.
São exemplos de requisitos não-funcionais:
· "a base de dados deve ser protegida para acesso apenas de usuários autorizados".
· "o tempo de resposta do sistema não deve ultrapassar 30 segundos".
· "o software deve ser operacionalizado no sistema Linux"
· "o tempo de desenvolvimento não deve ultrapassar seis meses".
Validação de requisitos
É o processo pelo qual se verifica se os requisitos elicitados definem o sistema que o cliente realmente quer. A validação também é importante, uma vez que o custo para remover erros de requisitos é grande, quando descobertos tardiamente.
Durante o processo de validação de requisitos, diferentes tipos de verificação devem ser efetuados no documento de requisitos. Essas verificações incluem:
1. Validade - O sistema fornece as funções que melhor atendem as necessidades de todos os usuários?
2. Consistência - Existem conflitos de requisitos?
3. Completeza - Todas as funções necessárias foram incluídas?
4. Realismo - Os requisitos podem ser implementados com a tecnologia e orçamento disponíveis?
5. Verificabilidade - Os requisitos podem ser checados?
 
Uma série de técnicas de validação podem ser utilizadas individualmente ou em conjunto, tais como:
1. Revisões de requisitos - é feita uma análise manual sistemática dos requisitos;
2. Prototipação - um modelo executável do sistema é demonstrado para os usuários finais para checar os requisitos;
3. Geração de casos de teste - os requisitos devem ser testáveis, para tal, devem-se desenvolver testes para os requisitos a fim de verificar a testabilidade.
WEBAULA 2
Unidade 2 – Gerenciamento de Requisitos
 
O gerenciamento de requisitos é o processo de controlar as mudanças nos requisitos durante o processo de engenharia de requisitos e desenvolvimento. Torna-se necessário manter o acompanhamento dos requisitos individuais e manter as ligações entre os requisitos dependentes, de modo que seja possível avaliar os impactos das mudanças de requisitos.
Considerando que os requisitos são inevitavelmente incompletos e inconsistentes, novos requisitos surgem durante o processo de desenvolvimento e os diferentes pontos de vista que esses requisitos possuem frequentemente são contraditórios.
Existem várias razões pelas quais as mudanças são inevitáveis, dentre elas destacam-se:
· A prioridade dos requisitos de diferentes pontos de vista se modificam;
· As pessoas que pagam pelo sistema podem especificar os requisitos de maneira conflitante com os requisitos das pessoas que irão utilizar o sistema;
· A empresa e o ambiente técnico do sistema se modificam durante o seu desenvolvimento.
 
Evolução dos requisitos
       Do ponto de vista da evolução, os requisitos dividem-se em duas classes:
 
· Requisitos permanentes
São requisitos estáveis, derivados da atividade principal da organização. Ex. Em um hospital, sempre haverá requisitos relativos aos pacientes, aos médicos, às enfermeiras a aos tratamentos.
· Requisitos voláteis
São requisitos que se modificam durante o desenvolvimento ou quando o sistema está em uso. Requisitos resultantes de políticas governamentais. Ex.: planos de assistência médica.
Os requisitos voláteis podem ser classificados em:
· Requisitos mutáveis - Requisitos que se modificam por causa do ambiente do sistema que está operando.
· Requisitos emergentes - Requisitos que surgem à medida que a compreensão do sistema pelo cliente progride durante o desenvolvimento do sistema.
· Requisitos consequentes - Requisitos que resultam da introdução do sistema de computador, onde podem ser criadas novas formas de trabalho, que geram novos requisitos de sistema.
· Requisitos de compatibilidade - Requisitos que dependem de outros sistemas ou processos de negócio específicos dentro da organização.
 
Gerenciamento de mudanças de requisitos
A figura abaixo mostra o processo de gerenciamento de requisitos, o qual deve ser aplicado a todas as mudanças propostas aos requisitos. A vantagem de se usar um método formal para gerenciar as mudanças está no fato de que as propostas são tratadas consistentemente e a documentação dos requisitos é feita de maneira controlada.
 
       Existem três estágios no processo de gerenciamento de mudanças, que são:
· Análise do problema e especificação da mudança.
         Discutem-se os problemas com os requisitos e propõem-se mudanças.
· Análise e custo da mudança.
         Avaliam-se os efeitos da mudança em outros requisitos do sistema.
· Implementação das mudanças.
       O documento de requisitos e outros documentos são alterados de forma a refletir as mudanças.
 
Técnicas de Requisitos
A seguir apresentaremos algumas técnicas para o levantamento e análise de requisitos:
· Levantamento baseado em pontos de vista;
· Entrevistas;
· Cenários de utilização do sistema;
· Etnografia (análise do ambiente de trabalho dos usuários).
 
Levantamento baseado em pontos de vista
As abordagens baseadas em pontos de vista têm como ponto forte o reconhecimento de várias perspectivas, fornecendo um framework para descobrir conflitos nos requisitos propostos por diferentes stakeholders.
Sistemas médios e grandes possuem diferentes tipos de usuários finais:
· Pessoas envolvidas com o sistema possuem diferentes interesses e pontos de vista a respeito do sistema;
· A análise desta multiperspectiva é importante para se descobrir e esclarecer os requisitos conflitantes propostos por diferentes usuários.
 
Entrevistas
Fazem parte da maioria dos processos de engenharia de requisitos. Nestas entrevistas, a equipe de engenheiros formula questões para os stakeholders sobre o sistema a ser desenvolvido.
As entrevistas podem ser abertas, em que o stakeholder responde um conjunto de perguntas predefinidas, ou fechadas, nas quais não há um roteiro definido, onde o engenheiro explora vários assuntos com os stakeholders no sistema, desenvolvendo assim uma maior compreensão das suas necessidades.
As entrevistas são úteis para se obter um entendimento geral sobre o que os stakeholders fazem, como eles podem interagir com o sistema e as dificuldades que enfrentam com o sistema atual, porém não são eficientes para elicitação de conhecimento sobre os requisitos e suas restrições.
Cenários de utilização do sistema
Geralmente, as pessoas consideram mais simples relatar exemplos da vida real a que abstrair descrições, desta forma, os cenários podem ser descritos e criticados por eles como uma forma de interação com o sistema de software.
Os cenários são úteis para adicionar detalhes a um esboço da descrição de requisitos, onde cada cenário abrange uma ou mais interações possíveis. Assim sendo, diversos cenários foram desenvolvidos, cada um dos quais fornecendo diferentes tipos de informações sobre o sistema em diversos níveis de detalhamento.
Descrições de cenários incluem:
· Estado do sistema no início do cenário;
· Fluxo normal de eventos no cenário;
· O que pode sair errado e como lidar com isso;
· Outras atividades concorrentes;
· Estado do sistema no final do cenário.
 
Etnografia(análise do ambiente de trabalho dos usuários)
É uma técnica de observação que pode ser usada na compreensão dos requisitos sociais e organizacionais, na qual um analista se insere no ambiente de trabalho onde o sistema será usado, observa o trabalho do dia a dia e anota as tarefas reais nas quais os participantes estão envolvidos.
Denota-se o valor desta técnica na ajuda prestada aos analistas para se descobrir os requisitos implícitos de sistemas que refletem os processos reais, e não os formais no qual as pessoas estão envolvidas.
A etnografia é particularmente eficaz para descobrir:
· Requisitos derivados da maneira como as pessoas realmente trabalham, ao invés da maneira pela qual as definições de processo dizem o que deveria fazer.
· Requisitos derivados da cooperação e do conhecimento das atividades de outras pessoas.
A etnografia pode e deve ser combinada com a prototipação, pois informa o desenvolvimento do protótipo de tal forma que poucos ciclos de refinamento sejam necessários.
Uma vantagem da etnografia é que ela pode revelar detalhes importantes do processo, que frequentemente são ignorados por outras técnicas, porém, não é apropriada para obter os requisitos organizacionais e de domínio. Assim sendo, a etnografia não é uma abordagem completa para a elicitação de requisitos, então devendo ser usada como complemento de outras abordagens como, por exemplo, a de cenários.