Aula 6 texto

PROF . HORACIO

Disciplina: REQUISITOS DE SISTEMAS Aula 06: ENGENHARIA DE REQUISITOS E ESTUDOS DE VIABILIDADE

Nesta aula, você irá: • • • •

Identificar o conceito e os processos de engenharia de requisitos.

Identificar o conceito sobre viabilidade de requisitos.

Reconhecer a importância da atividade de análise de viabilidade.

Realizar a análise de viabilidade de um projeto de software.

Introdução da aula

Quando nos referimos a atividade de estudo de viabilidade, estamos concentrados, no contexto da fase inicial a qualquer projeto de software, na realização de um “checklist” sobre os problemas identificados e que deverão ser solucionados.

Portanto, como resultado do estudo de viabilidade, é possível determinar pontos críticos do projeto, o que se tem de diferentes alternativas de soluções para o problema e, até mesmo, a conclusão de que o projeto tem realmente condições de ser finalizado, ou seja, será levado adiante ou não.

De maneira pagmática, na atividade vinculada ao estudo de viabilidade incide de um documento com formato previamente definido e que tem a importante missão de descrever,de maneira geral: o problema a ser tratado; a proposta e o plano do projeto; e as soluções acompanhadas de análises comparativas entre elas.

Livro SOMMERVILLE, I., Engenharia de Software, 9ª Edição. Pearson, 2011. Capítulo 4: Engenharia de Requisitos.

Aprenda mais!

Para saber mais sobre os tópicos estudados nesta aula, pesquise na internet sites, vídeos e artigos relacionados ao conteúdo visto. Se ainda tiver alguma dúvida, fale com seu professor online utilizando os recursos disponíveis no ambiente de aprendizagem.

Nesta aula, você:

PROF . HORACIO

- Aprendeu o conceito de engenharia de requisitos.

- Compreendeu o conceito de estudos de viabilidade.

- Aprendeu a importância da atividade de estudos de viabilidade.

- Analisou o que deve ser tratado em um documento de estudos de viabilidade..

Próxima aula

Na próxima aula, você estudará sobre os assuntos seguintes: - O conceito de estudos de elicitação de requisitos.

- O processo e as atividades da elicitação de requisitos.

- A contribuição da elicitação de requisitos na engenharia de software.

1) Qual a premissa básica para a engenharia de requisitos: a. Como fazer e o que fazer? b. Como fazer? c. O que fazer? (resposta certa) d. Definir o stakeholder. e. Definir uma estrutura de software.

2) É processo da engenharia de requisitos: a. Definir stakeholders. b. Analisar requisitos. (resposta certa) c. Definir uma estrutura de software. d. Definir arquitetura de rede. e. Definir sistema gerenciador de banco de dados.

3) Qual o objetivo da análise de viabilidade sobre um determinado projeto? a. Gerar um relatório sócio-ambiental do projeto. b. Gerar um relatório técnico da área de TI. c. Gerar um relatório para os fornecedores envolvidos no projeto. d. Gerar um relatório sobre os custos, prazos e benefícios do projeto. (resposta certa) e. Gerar um relatório de financeiro do projeto.

Conteúdo Online Seja bem-vindo a II Unidade de nossa disciplina!

PROF . HORACIO

Nessa etapa iremos imergir detalhar nos conteúdos sobre a engenharia de requisitos, inclusive nossa aula de hoje iniciar pelos fundamentos dessa área, destacando a importância no resultado de um software que atenda as necessidades dos usuários.

Serão trabalhadas quatro atividades da área de requisitos, com base na seguinte ordem: Aula 6 - Viabilidade.

Aula 7 – Elicitação.

Aula 8 – Validação.

Aula 9 – Gerenciamento.

Estas atividades fazem parte do que definimos como processo de engenharia de requisito. Lembre-se que não temos um comportamento e necessidade uniforme na área de software. Quando decidimos construir um sistema, certamente temos uma necessidade e um perfil que nos torna único, portanto, “em praticamente todos os sistemas os requisitos mudam.” (Sommerville, 2009). Com base nesse cenário, tornar-se necessário então a padronização o procedimento, para ter maior convicção da acertabilidade do que está sendo desenvolvido.

Portanto, caso mantenha o curso em atuar na área de engenharia de software, certamente lhe será requerido conhecer bem sobre as atividades que iremos destacar a partir dessa aula. Conforme mencionado, inicialmente trataremos sobre a engenharia de requisitos.

Vamos lá!

PROF . HORACIO Engenharia de Requisitos Engenharia é uma palavra que costuma sempre nos lembrar sobre processos relacionados a criação, ampliação e/ou reforma. Também é comum pensarmos em criação – mediante a engenharia civil. Então, quando pensamos em um engenheiro, estamos pensando em algum tipo de construção. Pois bem, existem várias variáveis que o profissional da área de atentar-se antes de simplesmente, por exemplo, estudar as composições físicas ou químicas mais apropriadas. Para isso, ele precisa averiguar!

Portanto, quando falamos em engenharia de requisitos, estamos a tratar de um processo que define atividades para uma produção e manutenção adequada (lembrando que esse documento serve para todos os envolvidos, necessitando cobrir as necessidades tanto em termos técnicos como de áreas comuns), do documento de requisitos de software, o qual foi estudado na unidade anterior. Este importante documento para direcionamento do sistema a ser desenvolvidos. Para atingir esse objetivo, temos uma sistematização de um processo para definir o perfil do software.

A premissa básica então para a engenharia de requisitos de software é definir o que deve ser feito; ou seja, é um trabalho de interpretação. Ela não se preocupa no como deve fazer feito. Com isso, questões tecnológicas como linguagem de programação, sistema gerenciador de banco de dados, topologias de redes de computadores, não representam o cerne a ser detalhado, mas sim todas as necessidades que os “humanos” esperam da “máquina”.

Na figura 1, temos a definição do processo de engenharia de requisitos:

Figura 1 - Processo da Engenharia de Requisitos

PROF . HORACIO Conforme citado no início de nossa aula, teremos uma aula para tratar cada um dos componente do processo. Por enquanto, trataremos apenas de explicar o modelo de maneira geral.

O estudo de viabilidade aponta então se o projeto está adequado para responder a contento ao que a empresa quer, e que esteja apoiado nas condições dos recursos disponíveis. Este gera então um relatório a qual aponta as conclusões e devidas justificativas. Ou seja, o projeto pode ser cancelado antes mesmo de qualquer digitação de linha de código.

Na análise de requisitos, segundo passo do processo, que busca identificar entre os stakeholders as funcionalidades ideais e fundamentais para o software.

Definição dos requisitos, como o nome já sugere, é responsável em receber todas as informações referente a análise de requisitos e promover então o que será especificado como requisito para o sistema que será definido.

Por fim, a fim de consolidar o processo com o nível de detalhe e especificidade necessários, são descritos todos os requisitos que já estão definidos.

Importante observar que a partir do 2º passo (análise de requisitos), temos setas bidirecionais, que estabelecem que pode haver um retorno dentre as atividades, principalmente mediante a identificação de um erro na fase anterior àquela que está sendo executada no momento. Lembre-se que ao término do processo, tudo que estiver contido no documento de requisito de software deve ser atendido plenamente; portanto, o lapso culminará em um sistema sem qualidade.

No contexto Na figura 2 está disposta um modelo mais completo, em espiral, do processo de engenharia de requisitos, segundo proposta por Sommerville (2011):

PROF . HORACIO

Figura 2 - Processo de Engenharia de Software em Espiral (Sommerville, 2011)

Cada uma das atividades ser谩 detalhada a partir dessa e nas pr贸ximas 3 aulas.

Bons estudos!

PROF . HORACIO Estudos de Viabilidade Para todo projeto que estimamos realizar, seja ele para nós ou para a empresa a qual colaboramos, uma pergunta muito básica e fundamental sempre deve ser respondida:

Será que contribui para os meus objetivos?

Fonte da figura: http://t0.gstatic.com/images?q=tbn:ANd9GcRj9f_AdCSgYjjlkWPB6T7ejCJ6pfbxJBnL

Uma estimativa realizada para verificar se as necessidades do usuário podem ser satisfeitas usando correntes de software e hardware, à custo e prazo efetivo.

A partir então do resultado alcançado da reflexão a partir desse questionamento, é que No tocante a área da tecnologia da informação e que estamos estudando, vamos então adicionar os seguintes questionamentos: 1. Dadas as restrições tecnológicas, organizacionais (econômicas, políticas, ambientais, recursos disponíveis) e temporais associadas ao projeto, será que o sistema pode ser implementado?

2. Caso haja necessidade de internação entre diferentes sistemas, será que esta é possível?

Conforme o nome sugere, pretende-se com este estudo avaliar se, de um ponto de vista tecnológico e organizacional, se o projeto é viável e se representará uma solução capaz de ser executada e de agregar valor. Portanto, muito antes de pensarmos em requisitos, temos que saber se o sistema pode ser concluído e/ou mantido, por exemplo.

São outros exemplos de questões que devem ser avaliadas: 

De que forma é que o sistema irá contribuir diretamente para os objetivos da organização?



Se o novo sistema não fosse implementado, quais seriam as alternativas para a organização?



Quais são os problemas que os sistemas atuais apresentam e como é que um sistema novo irá resolver estas falhas?

PROF . HORACIO 

É possível a integração com os outros sistemas da organização (de um ponto de vista tecnológico)?



Com que facilidade é que se consegue partilhar informação entre estes sistemas?

Analisando dos itens supracitados, percebemos que a questão mais crítica é a primeira, já que um sistema que não contribua para os objetivos da organização não lhe traz qualquer valor acrescentado e como tal a sua existência não se justifica. Apesar de parecer óbvio, frequentemente constata-se que um determinado software não contribuem para os objetivos das respectivas organizações, quer seja por interesses externos (políticos ou organizacionais) ou por falta de clareza na definição dos objetivos da organização, porém ele foi desenvolvido ou até mesmo já adquirido.

No estudo de viabilidade, é comum termos várias fontes de informações. Tipicamente, temos os seguintes stakeholders: a) Quem poderá fornecer esta informação serão os utilizadores dos sistemas atuais e do sistema a implementar. b) Os responsáveis pelos departamentos nos quais o sistema será usado. c) Técnicos que estejam familiarizados com as tecnologias envolvidas (do novo sistema e dos sistemas existentes). d) Responsáveis pela manutenção futura do sistema a implementar e, de um modo geral, todos aqueles que terão qualquer tipo de interação com o novo sistema (ou que sejam por ele afetados).

Deve, portanto identificar-se que informação é necessária para responder a estas questões e quem possui esta informação, procedendo-se de seguida a escolha de todos os dados disponíveis para permitir mais exatidão e visões no âmbito do projeto, permitindo realmente avaliar a sua viabilidade.

A partir das conclusões obtidas, outra atividade no processo de estudo de viabilidade é a produção de um relatório e deverá determinar a continuação do desenvolvimento do projeto, tornando mais claras as restrições (econômicas, temporais e organizacionais) do projeto e definindo mesmo alguns requisitos de alto nível.

Acompanhe abaixo um exemplo resumido de um relatório referente a um estudo de viabilidade Fonte: (http://fatecsjc1.wordpress.com/relatorio-de-viabilidade/)

Relatório de viabilidade Objetivos Gerais da organização

PROF . HORACIO

Hoje o número de pessoas que acessam à Internet é muito grande, principalmente entre os jovens. Eles passam horas em bate papos on-line, sites de relacionamentos como o Orkut, jogos on-line e fazem tudo que podem pela Internet, até namorar.

A facilidade com que se compra on-line hoje também é muito grande, a segurança está bem maior, e para um maníaco por Internet esta facilidade seria muito bem vinda.

Para a empresa, iria abranger um nicho de mercado ainda inexplorado na nossa região, um mercado aberto com clientes em potencial. O fato de ele receber os dados em seu micro e imprimi-lo, praticamente zera os erros tão freqüentes em ligações, como endereço errado, troco errado, esquecimento de detalhes, como não colocar cebola…

Outra facilidade é que o pagamento por cartão de débito e crédito minimiza o problema dos trocos tão raros hoje, e assalto em relação ao moto-boy, já que na entrega não haveria transporte de dinheiro, e também o gerente não tem que se preocupar se vai receber ou não, porque o dinheiro já foi depositado na conta da empresa.

Mais uma vantagem é o fato do software gerar um relatório, com a quantidade de pizzas vendidas por dia semana ou mês, valor, pizzas mais pedidas, locais mais pedidos, clientes mais fiéis, etc.

Tecnologias, Custos e Prazos A implementação é bem simples, já que toda pizzaria hoje em dia já tem um computador, e que caso não tenha os requisitos mínimos de hardware e software para o sistema, é bem leve, não necessitando de um alto investimento nesse ponto, o acesso à Internet nos centros da cidade não é um problema e hoje em dia a tendência é melhorar cada vez mais, o conhecimento exigido para o uso do software é bem pequeno, mas há um treinamento para o usuário já contemplado neste projeto.

Os custos para implementação são bem baixos em relação a um novo mercado ainda inexplorado, e levando-se em consideração que não é necessário a compra de equipamentos sofisticados, e que a evolução da tecnologia não afeta negativamente o funcionamento do site.

O prazo para implementação é bem reduzido, com acompanhamento da evolução por parte do cliente o que torna o custo do projeto acessível.

Caso a empresa já tenha um site, não há problema nenhum porque podemos colocar um link nesse site para direcionar para o pizza on-line.

Em relação ao software de controle interno da pizzaria, também não afetará já que o sistema pode gerar relatórios tanto para impressão ou até comunicação com o software existente, para isso no entanto precisará de um estudo prévio do software para verificar a compatibilidade.

PROF . HORACIO

Mediante o disposto no texto do relatório, percebemos que trata-se de um software para venda de pizza através da internet. Acompanhe alguns pontos da apresentação do sistema: 1) É proposto o desenvolvimento de um sistema para Pizzaria online que inclui cadastros de clientes e um cadastro de produtos (Cardápio da Pizzaria) divulgados no site.

2) O objetivo do sistema consiste em aperfeiçoar os serviços prestados pela pizzaria evitando diminuir falhas humanas (Ex.: Eu não pedi pizza com cebola) e reduzir o tempo de entrega, economizar em custos telefônicos e rapidez no atendimento ao cliente.

3) A PO possui propriedades emergentes funcionais como o controle e organização de cadastro de clientes e não funcionais como a usabilidade e acessibilidade do mesmo.

Analisando então o teor do relatório, percebemos que é necessário contextualizar a empresa em todo o seu negócio, analisar então custos e prazos nas necessidades vinculadas para uma solução; por fim, demonstrar a rentabilidade do projeto, principalmente mediante o que será agregado para a empresa.