• Nenhum resultado encontrado

ENGENHARIA DE REQUISITOS

N/A
N/A
Protected

Academic year: 2022

Share "ENGENHARIA DE REQUISITOS"

Copied!
201
0
0

Texto

(1)

ENGENHARIA DE REQUISITOS

Professora Me. Vanessa Ravazzi Perseguine

GRADUAÇÃO

Unicesumar

(2)

Ficha catalográfica elaborada pelo bibliotecário João Vivaldo de Souza - CRB-8 - 6828

Reitor

Wilson de Matos Silva Vice-Reitor

Wilson de Matos Silva Filho Pró-Reitor de Administração Wilson de Matos Silva Filho Pró-Reitor de EAD

Willian Victor Kendrick de Matos Silva Presidente da Mantenedora Cláudio Ferdinandi

NEAD - Núcleo de Educação a Distância Direção Operacional de Ensino Kátia Coelho

Direção de Planejamento de Ensino Fabrício Lazilha

Direção de Operações Chrystiano Mincoff Direção de Mercado Hilton Pereira

Direção de Polos Próprios James Prestes

Direção de Desenvolvimento Dayane Almeida

Direção de Relacionamento Alessandra Baron

Gerência de Produção de Conteúdo Juliano de Souza

Supervisão do Núcleo de Produção de Materiais

Nádila de Almeida Toledo Coordenador de Conteúdo Fabiana De Lima

Design Educacional Yasminn Zagonel Projeto Gráfico Jaime de Marchi Junior José Jhonny Coelho Editoração

Humberto Garcia da silva Revisão Textual

Viviane Favaro Notari/Yara Martins Dias Ilustração

André Luís Onishi C397 CENTRO UNIVERSITÁRIO DE MARINGÁ. Núcleo de Educação a

Distância; PERSEGUINE, Vanessa Ravazzi

Engenharia de Requisitos. Vanessa Ravazzi Perseguine.

Maringá-Pr.: UniCesumar, 2017. Reimpressão, 2021.

158 p.

“Graduação - EaD”.

1. Engenharia. 2. Software. 3. Gestão EaD. I. Título.

ISBN 978-85-459-0111-2

CDD - 22 ed. 620 CIP - NBR 12899 - AACR/2

(3)

Viver e trabalhar em uma sociedade global é um grande desafio para todos os cidadãos. A busca por tecnologia, informação, conhecimento de qualidade, novas habilidades para liderança e so- lução de problemas com eficiência tornou-se uma questão de sobrevivência no mundo do trabalho.

Cada um de nós tem uma grande responsabilida- de: as escolhas que fizermos por nós e pelos nos- sos farão grande diferença no futuro.

Com essa visão, o Centro Universitário Cesumar assume o compromisso de democratizar o conhe- cimento por meio de alta tecnologia e contribuir para o futuro dos brasileiros.

No cumprimento de sua missão – “promover a educação de qualidade nas diferentes áreas do conhecimento, formando profissionais cidadãos que contribuam para o desenvolvimento de uma sociedade justa e solidária” –, o Centro Universi- tário Cesumar busca a integração do ensino-pes- quisa-extensão com as demandas institucionais e sociais; a realização de uma prática acadêmica que contribua para o desenvolvimento da consci- ência social e política e, por fim, a democratização do conhecimento acadêmico com a articulação e a integração com a sociedade.

Diante disso, o Centro Universitário Cesumar al- meja ser reconhecido como uma instituição uni- versitária de referência regional e nacional pela qualidade e compromisso do corpo docente;

aquisição de competências institucionais para o desenvolvimento de linhas de pesquisa; con- solidação da extensão universitária; qualidade da oferta dos ensinos presencial e a distância;

bem-estar e satisfação da comunidade interna;

qualidade da gestão acadêmica e administrati- va; compromisso social de inclusão; processos de cooperação e parceria com o mundo do trabalho, como também pelo compromisso e relaciona- mento permanente com os egressos, incentivan- do a educação continuada.

(4)
(5)

Seja bem-vindo(a), caro(a) acadêmico(a)! Você está iniciando um processo de transformação, pois quan- do investimos em nossa formação, seja ela pessoal ou profissional, nos transformamos e, consequente- mente, transformamos também a sociedade na qual estamos inseridos. De que forma o fazemos? Criando oportunidades e/ou estabelecendo mudanças capa- zes de alcançar um nível de desenvolvimento compa- tível com os desafios que surgem no mundo contem- porâneo.

O Centro Universitário Cesumar mediante o Núcleo de Educação a Distância, o(a) acompanhará durante todo este processo, pois conforme Freire (1996): “Os homens se educam juntos, na transformação do mundo”.

Os materiais produzidos oferecem linguagem dialó- gica e encontram-se integrados à proposta pedagó- gica, contribuindo no processo educacional, comple- mentando sua formação profissional, desenvolvendo competências e habilidades, e aplicando conceitos teóricos em situação de realidade, de maneira a inse- ri-lo no mercado de trabalho. Ou seja, estes materiais têm como principal objetivo “provocar uma aproxi- mação entre você e o conteúdo”, desta forma possi- bilita o desenvolvimento da autonomia em busca dos conhecimentos necessários para a sua formação pes- soal e profissional.

Portanto, nossa distância nesse processo de cres- cimento e construção do conhecimento deve ser apenas geográfica. Utilize os diversos recursos peda- gógicos que o Centro Universitário Cesumar lhe possi- bilita. Ou seja, acesse regularmente o AVA – Ambiente Virtual de Aprendizagem, interaja nos fóruns e en- quetes, assista às aulas ao vivo e participe das discus- sões. Além disso, lembre-se que existe uma equipe de professores e tutores que se encontra disponível para sanar suas dúvidas e auxiliá-lo(a) em seu processo de aprendizagem, possibilitando-lhe trilhar com tranqui- lidade e segurança sua trajetória acadêmica.

(6)

Professora Me. Vanessa Ravazzi Perseguine

Mestre em Ciências da Computação. Especialista em Gestão e Coordenação Escolar. Especialista em Gestão de Projetos. Graduada em Ciência da Computação. Experiencia na Gestão de TI órgão Público, Coordenação de cursos e projetos. Experiência na área de Ciências da Computação, atuando nas áreas: engenharia de software, lógica e algoritmos e gerencia de projetos.

A UT ORES

(7)

SEJA BEM-VINDO(A)!

Olá! Seja bem-vindo(a) à disciplina Engenharia de Requisitos. Neste curso, iremos abor- dar as atividades da engenharia de requisitos e sua importância no processo de desen- volvimento de software. Nesse contexto, gostaria que considerasse o seguinte: mesmo para engenheiros de software experientes, é complexo gerir todas as especialidades envolvidas no processo de desenvolvimento de software.

Via de regra, os softwares são desenvolvidos para um conhecimento específico, em que se faz necessário um entendimento prévio do modelo de negócio para o qual o software será desenvolvido. Por exemplo, se o software é para o gerenciamento de uma locadora de vídeos, o desenvolvedor deverá entender sobre o negócio locar vídeos; se o software tem a responsabilidade de emitir demonstrativos contábeis, o responsável pelo seu de- senvolvimento terá que conhecer todos os dados necessários a serem levantados para os cálculos contábeis e posterior emissão desses relatórios; ou, ainda, se o software é responsável pelo monitoramento dos dados que mantém atividades de sobrevivência que trará de volta à terra o astronauta que foi a Marte, o profissional responsável terá que aprender todas as condições e exigências que deverão ser controladas. Para a entre- ga de um produto de qualidade, que atenda às expectativas do cliente e que execute o que se é esperado, é de extrema importância que os responsáveis pelo desenvolvimen- to do software conheçam o ambiente onde o software será inserido.

Calma! Não se assuste! Não estou dizendo que terá que fazer uma faculdade sobre a es- pecialidade de cada software que irá desenvolver, ou supervisionar o desenvolvimento, o que eu pretendo deixar claro é que tão importante quanto desenvolver o software,

“botar a mão na massa”, é o planejar o que será desenvolvido. O tempo destinado ao planejamento é uma discussão antiga e a gestão de projetos está em evidência mundial.

Casos de sucesso e a utilização de técnicas ágeis, modeladas para o desenvolvimento de software, estão promovendo a desburocratização do processo de software, princi- palmente nas fases de planejamento e controle, o que tem impulsionado as empresas para a sistematização dos processos internos e a adoção de boas práticas de desenvolvi- mento de software. Dentro da engenharia de software, podemos considerar como parte do planejamento o estabelecimento de um processo de software, e a engenharia de re- quisitos é a atividade do processo de software responsável por recolher as informações sobre o ambiente de negócio em que o software será inserido, interpretar para os de- senvolvedores o propósito do software e projetar as respostas esperadas pelos usuários.

Além de entender como a engenharia de requisitos se situa nos processos de enge- nharia de software, no decorrer desta disciplina, estudaremos os fundamentos da en- genharia de requisitos, os processos, como gerenciar requisitos e controlar mudanças e teremos um breve olhar sobre como as metodologias ágeis de desenvolvimento de software tratam as atividades da engenharia de requisitos.

Vamos começar nossos estudos?

Boa leitura!

APRESENTAÇÃO

ENGENHARIA DE REQUISITOS

(8)

SUMÁRIO

UNIDADE I

ENGENHARIA DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE

13 Introdução

14 Engenharia de Requisitos no Contexto da Engenharia de Software 16 Processo de Software

20 Modelo de Processo de Software

21 Atividades Fundamentais do Processo de Software 23 Importância da Engenharia de Requisitos no Processo de

Desenvolvimento de Software 27 Considerações Finais

UNIDADE II

FUNDAMENTOS DA ENGENHARIA DE REQUISITOS

35 Introdução

36 Conceitos Fundamentais da Engenharia de Requisitos 37 Stakeholders

40 Classificação dos Requisitos

48 Documentação dos Requisitos de Software 53 Matriz de Rastreabilidade de Requisitos

54 Template da Matriz de Rastreabilidade de Requisitos 56 Considerações Finais

(9)

SUMÁRIO

09

UNIDADE III

PROCESSOS DA ENGENHARIA DE REQUISITOS

67 Introdução

68 Processos da Engenharia de Requisitos 69 Levantamento e Análise de Requisitos 88 Negociação

90 Validação dos Requisitos 94 Especificação de Requisitos 105 Considerações Finais

UNIDADE IV

GESTÃO DE REQUISITOS

115 Introdução

116 Evolução dos Requisitos 118 Rastreabilidade

123 Controle de Mudanças 127 Considerações Finais

(10)

SUMÁRIO

UNIDADE V

REQUISITOS NAS METODOLOGIAS ÁGEIS

135 Introdução

136 Requisitos nas Metodologias Ágeis 137 Manifesto Ágil

140 SCRUM

143 Especificação de Requisitos Ágeis 146 Considerações Finais

151 Conclusão 153 Referências 158 Gabarito

(11)

UNIDADE

I

Professora Me. Vanessa Ravazzi Perseguine

ENGENHARIA DE REQUISITOS NO CONTEXTO DA

ENGENHARIA DE SOFTWARE

Objetivos de Aprendizagem

■ Apresentar conceitos básicos da engenharia de software.

■ Contextualizar a engenharia de requisitos no processo de software.

Plano de Estudo

A seguir, apresentam-se os tópicos que você estudará nesta unidade:

■ Engenharia de requisitos no contexto da engenharia de software

■ Processo de software

■ Modelo de processo de software

■ Atividades fundamentais do processo de software

■ Importância da engenharia de requisitos no processo de desenvolvimento de software

(12)
(13)

INTRODUÇÃO

Olá, caro(a) aluno(a)! Começamos nossos estudos apresentando a engenharia de requisitos no contexto da engenharia de software. Nesta unidade, revisitare- mos alguns conceitos importantes, necessários para a compreensão dos objetivos da engenharia de requisitos.

Passaremos pelo software que se tornou elemento fundamental no mer- cado atual, a ponto de se tornar uma espécie de carteira de investimento para os empresários (Gestão de Ativos de Software) e finalizaremos com o entendi- mento dos processos fundamentais envolvidos nas atividades de desenvolvimento de software.

A Engenharia de Software envolve um conjunto de etapas que inclui méto- dos, ferramentas e procedimentos que possibilitam o controle do processo de desenvolvimento de software, ocupando-se de todos os aspectos, desde os estágios iniciais de especificação do sistema até sua manutenção (evolução). A Engenharia de Requisitos é uma espécie de subárea da Engenharia de Software, com o obje- tivo principal de obter um Documento de Requisitos correto e completo.

Ouso afirmar, concordando com vários estudiosos da área, que engenha- ria de requisitos é a disciplina do ciclo de vida do desenvolvimento de software que tem influência direta, ou uma das mais diretas, sobre o sucesso ou fracasso de qualquer projeto.

A inclusão de técnicas maduras e comprovadas de gestão de requisitos ofe- rece, dentre outros benefícios, o aumento da satisfação do usuário, que é o principal indicador de qualidade do sistema, e, também, a redução de custos na construção e manutenção de um sistema. Se os requisitos forem bem definidos e gerenciados, existe uma real garantia de que o sistema atingirá seu objetivo em uma primeira tentativa, o que garante uma redução do custo total do sistema.

Assim, nosso objetivo nesta unidade é entender a base da engenharia de requisitos, conhecendo os processos que a sustentam. Vamos lá!?

Introdução

Reprodução proibida. Art. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.

13

(14)

ENGENHARIA DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE

Reprodução proibida. Art. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.

U N I D A D E I 14

ENGENHARIA DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE

Para entendermos a importância da engenharia de requisitos durante a definição de um software, é necessário identificar onde ela se encaixa no contexto da engenharia de software. Vamos refrescar a memória e contextu- alizar a engenharia de requisitos, relembrando rapidamente alguns conceitos fundamentais?

Primeiro, a partir da informática básica, o que é software? Fácil! Imediatamente nos vem à memória: “conjunto de instruções”; “parte lógica”; “programas para computador”; “sistemas que controlam o funcionamento de um computador”.

Perfeito! Mantenha isso em mente.

Agora, da base do nosso curso, como você define engenharia de software?

Quando penso em engenharia de software, lembro-me de “ferramentas”; “pro- cesso”; “sistematização”; “controle”; “metodologia”. A IEEE Standard 24765-2010, define engenharia de software como “a aplicação de uma abordagem sistemática, disciplinada e quantificável para o desenvolvimento, operação e manutenção de software”.

Correlacionando, temos, então, que software é um conjunto de instruções a ser executado por um computador, e engenharia de software é a abordagem sistemática que envolverá todos os aspectos de desenvolvimento do software:

o projeto, a análise e a construção do software para algum objetivo específico.

Aprofundando um pouco, para Pressman (2010), essa abordagem sistemá- tica a que me referi acima pode ser vista como uma tecnologia em camadas, conforme mostra a figura 1.

(15)

Engenharia de Requisitos no Contexto da Engenharia de Software

Reprodução proibida. Art. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.

15

Ferramentas Métodos Processos

Foco na Qualidade

Figura 1: Engenharia de software em camadas Fonte: adaptada de Pressman (2010).

Podemos assumir que a busca pela qualidade deve ser a base para todas as fases e atividades do processo de desenvolvimento do software, isto é, deve- mos manter Foco na Qualidade. Na camada Métodos, Pressman (2010) explica que estão os detalhes de como fazer para construir o software1 e, como está acima do processo, pode ser interpretada como uma camada de suporte, pois apoia as atividades de desenvolvimento, sistematizando-as e mensuran- do-as, de forma a garantir a manutenção da qualidade. A última camada, Ferramentas, no topo, garante apoio automatizado aos métodos. São as fer- ramentas computacionais, eletrônicas, ou outras que permitem automatização das atividades previstas pelo Processo e definidas no Método.

1 Neste ponto, é importante observar que existem métodos para as diferentes atividades do processo de desenvolvimento de software, por exemplo, as atividades da fase da especificação de software terão métodos diferentes dos das atividades da fase de projeto de software, que serão ainda diferentes das atividades dos métodos da fase de validação de software e assim por diante, vocês estudarão cada fase do processo de software como disciplinas do curso.

(16)

DESCRIÇÃO DE IMAGENS

PÁGINA 15 – Figura 1: Engenharia de software em camadas

INÍCIO DESCRIÇÃO – A imagem apresenta a Engenharia de software em camadas. A figura apresenta quatro círculos, com informações dentro que diminuem gradativamente. Sendo as seguintes informações da parte externa para a parte interna respectivamente:

Foco na qualidade, Processos, Métodos e Ferramentas.

FIM DESCRIÇÃO.

(17)

ENGENHARIA DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE

Reprodução proibida. Art. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.

U N I D A D E I 16

No modelo de engenharia de software de Pressman (2010), apresentado na Figura 2, o Processo se destaca como o elemento principal, responsável por definir a estrutura geral para o controle gerencial do desenvolvimento do sof- tware. É a camada processo que vai embasar e contextualizar quais métodos e ferramentas serão aplicados para o desenvolvimento de determinado produto de software, isto é, quais serão os produtos de trabalho, quais marcos serão defini- dos, como gerir as modificações propostas e se a qualidade está sendo mantida.

Na camada processo, é estabelecido o Projeto de Desenvolvimento do Software.

Ferramentas Métodos

Figura 2: Engenharia de Software em Camadas Fonte: adaptada de Roger S. Pressman (2010).

PROCESSO DE SOFTWARE

Percebemos que, tanto para o IEEE quanto para Pressman (2010), tão importante quanto o produto de software que é produzido é a forma como ele é produzido. A proposta das disciplinas da engenharia de software é nos habilitar para a criação de softwares com qualidade e que sigam as especificações de orçamento e pra- zos. Como? Por meio de processos adaptáveis que têm como propósitos tornar ágil o desenvolvimento, atender às particularidades de cada projeto e, principal- mente, alcançar a satisfação do cliente.

(18)

DESCRIÇÃO DE IMAGENS

PÁGINA 16 – Figura 2: Engenharia de Software em Camadas

INÍCIO DESCRIÇÃO –A imagem apresenta a Engenharia de software em camadas. A figura apresenta de forma gradativa quatro círculos sobrepostos sendo o primeiro denominado de Ferramentas, o segundo Métodos,o terceiro Processos e último Foco na qualidade.

FIM DESCRIÇÃO.

(19)

Processo de Software

Reprodução proibida. Art. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.

17

Então, a produção de um software bem-sucedido – assumindo somente três cri- térios: 1. cumpriu orçamento; 2. cumpriu prazo; 3. atendeu às expectativas do cliente – dá-se por meio do estabelecimento bem definido do processo de software.

Agora, pergunto: o que você entende por processo? Deixe de lado, por enquanto, seu aspecto técnico, vamos pensar na palavra processo de forma geral.

Se abrirmos um browser para Internet, digitarmos na caixa de pesquisa “defina processo”, e, se você optou pela ferramenta de pesquisa mais popular, serão apre- sentadas duas definições antes mesmo da apresentação da lista de links com os resultados encontrados2:

processo

substantivo masculino 1.

ação continuada, realização contínua e prolongada de alguma atividade; segui- mento, curso, decurso.

2.

sequência contínua de fatos ou operações que apresentam certa unidade ou que se reproduzem com certa regularidade; andamento, desenvolvimento, marcha.

Analisando essas definições, de forma geral, ambas nos remetem a uma atividade continuada, concorda? Faz-nos pensar em algo desenvolvido passo a passo. A seguir, vamos observar a definição que um dicionário nos apresenta sobre o tema.

2 Resultado da busca pelo termo “defina processo” no Google.

Por que, mesmo tendo disponíveis técnicas, metodologias testadas e ferra- mentas automatizadas, ainda existem tantos projetos de desenvolvimento de software fracassados?

Fonte: o autor.

(20)

ENGENHARIA DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE

Reprodução proibida. Art. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.

U N I D A D E I 18

O Aurélio3 define:

Significado de Processo

1. Método, sistema, modo de fazer uma coisa.

2. Conjunto de manipulações para obter um resultado.

3. O conjunto dos papéis relativos a um negócio.

4. Conjunto dos autos e mais documentos escritos numa causa cível ou criminal.

5. Processamento.

6. Seguimento, decurso.

7. Marcha das fases normais ou mórbidas dos fenômenos orgânicos.

8. Demanda, ação.

9. Processo sumário: aquele que, em atenção à brevidade, dispensa certas formalidades.

Deixando de lado os significados que fogem ao nosso contexto, como o ter- ceiro e o quarto, o dicionário nos apresenta processo como uma abordagem, uma forma adotada para se desenvolver algo.

Vamos consolidar? Processo é, então, uma atividade organizada em etapas específicas a serem desenvolvidas de forma contínua, que mantenha uma uni- dade, a fim de alcançar um propósito final.

Considerando que o nosso propósito final é o software (enquanto produto a ser desenvolvido) e de posse da nossa própria definição de processo, fica fácil concordar com Pressman (2010, p. 16) quando nos apresenta o processo de sof- tware como “um arcabouço para as tarefas que são necessárias para construir softwares de alta qualidade”.

3 Dicionário Aurélio (online).

(21)

Processo de Software

Reprodução proibida. Art. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.

19

Ótimo! Vamos juntar tudo?

O processo de software é um conjunto de atividades que nos orienta durante o desenvolvimento do software. Um processo irá determinar as responsabilida- des de cada um dos envolvidos, o prazo e quais ferramentas serão utilizadas.

Existem inúmeras propostas e sugestões para modelos de processo de sof- twares, todas baseadas em experiências bem ou malsucedidas. Não existe um processo ideal, o que a literatura propõe são “boas práticas” que podem ser adap- tadas para cada empresa ou profissional e, ainda assim, dentro da mesma empresa, para cada projeto, deve ser estabelecido seu próprio processo, considerando suas exigências e realidade comercial. Essas propostas são conhecidas como modelo de processo de software. Um processo de software pode ser visto como um con- junto de atividades organizadas e utilizadas para definir, desenvolver, testar e manter um software. Existem várias propostas de modelos de processo de sof- tware, as atividades básicas comuns entre elas, em geral, são: levantamento de requisitos; análise de requisitos; projeto; implementação; testes; implantação.

O conceito de Engenharia de Software surgiu na conferência da OTAN sobre Engenharia de Software (NATO Software Engineering Conference), em Gar- misch, Alemanha, organizada a fim de propor soluções para o que ficou histo- ricamente conhecido como “Crise de Software” no final da década de sessenta.

Hoje, mais de cinquenta anos depois da Crise do Software, percebemos que a grande maioria das empresas e dos profissionais de desenvolvimento de sof- tware ainda não consegue sucesso em seus projetos. Guinther de Bitencourt Pauli afirma em seu artigo que “o problema é que as abordagens tradicionais de engenharia de software ainda se baseiam em outros ramos de engenharia, como a civil e mecânica, onde os custos com planejamento são menores”.

Aprofunde seu conhecimento lendo o artigo disponível em:

<http://www.ancibe.com.br/artigos%20de%20si/artigo%20-%20Suces- sos%20em%20projetos%20de%20informatica%C3%A7%C3%A3o.pdf>.

Acesso em: 29 abr. 2015.

Fonte: o autor.

(22)

ENGENHARIA DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE

Reprodução proibida. Art. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.

U N I D A D E I 20

MODELO DE PROCESSO DE SOFTWARE

Um modelo de processo de software é um conjunto de métodos e ferramentas orientados para auxiliar no planejamento, desenvolvimento, controle e manu- tenção de um software.

Os modelos de processos de software foram sendo desenvolvidos aos poucos, conforme os especialistas esbarravam em um problema e analisavam a melhor forma de resolvê-lo, assim, também foram sendo desenvolvidas suas atualiza- ções, conforme a evolução do mercado de desenvolvimento de software.

Se recorrermos a uma pesquisa básica, na Internet mesmo, encontraremos vários modelos de processo de software propostos: linear (famoso cascata); incre- mental; orientada a reuso; baseado em componentes, espiral, processo unificado (quem nunca ouviu falar do RUP?); os, atualmente, mais explorados, os ágeis:

Scrum, TDD (Test Driven Development), ATDD (Acceptance test-driven develop- ment), BDD (BDD – Behavior driven development), XP (eXtreme Programming).

Enfim, são inúmeras as propostas existentes de modelos de processos para desen- volvimento de software. Qualquer modelo que você decida estudar, ainda que possua etapas e métodos diferentes, perceberá que apresenta os mesmos objeti- vos finais: cumprir o prazo, cumprir o custo, entregar um produto de qualidade e único; e, também, exige as mesmas condições: pessoas treinadas e motivadas, processos claros e definidos e ferramentas adequadas.

Na prática, o que precisamos identificar é o processo de software que melhor se adapte à realidade do nosso negócio e que atenda às necessidades de produ- ção do software a ser desenvolvido. Sommerville (2011, p. 19) me apoia nessa afirmação quando diz que: “não existe um processo ideal, a maioria das organi- zações desenvolve os próprios processos de desenvolvimento de software”.

Importante registrar que existe uma pequena distinção entre processo e modelo de software: o processo de software é intrínseco a qualquer novo pro- jeto de software, pois trata da necessidade de um software ser desenvolvido de forma completa e que atenda a todas as expectativas do cliente, enquanto o modelo é a forma onde serão trabalhados todos os passos para atingir os obje- tivos de desenvolver software.

(23)

Atividades Fundamentais do Processo de Software

Reprodução proibida. Art. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.

21

ATIVIDADES FUNDAMENTAIS DO PROCESSO DE SOFTWARE

Todo processo de software deve cumprir todas as etapas que foram estabelecidas para ele, ainda que você desenvolva o seu próprio modelo. Você deve estar se pergun- tando: que etapas são essas? As etapas são as atividades estabelecidas em conjunto com sua equipe de trabalho e que serão tratadas em cada uma das fases do processo.

Pressman (2010, p. 18) diz que

um arcabouço de processo estabelece o alicerce para um processo de software completo pela identificação de um pequeno número de ativi- dades aplicáveis a todos os projetos de software, independentemente de seu tamanho ou complexidade.

Sommerville (2011) considera as seguintes atividades como fundamentais para a engenharia de software: especificação de software; projeto de software; valida- ção de software; e evolução de software.

■ Especificação de software: define a funcionalidade do software e as res- trições sobre sua operação.

■ Projeto de software: define as funcionalidades que deverão ser desenvolvidas para que se obtenha como produto final o software especificado pelo cliente.

■ Validação de software: o software deve ser validado para garantir que faça o que o cliente deseja.

■ Evolução de software: o software deve evoluir para atender aos novos requisitos que, naturalmente, surgirão.

O software é um produto resultante de uma atividade cognitiva. A cognição está diretamente relacionada com fatores diversos, como o pensamento, a linguagem,

Uma linguagem de modelagem é suficiente no processo de desenvolvimen- to de um software?

Fonte: o autor.

(24)

ENGENHARIA DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE

Reprodução proibida. Art. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.

U N I D A D E I 22

a percepção, a memória e o raciocínio, que fazem parte do desenvolvimento inte- lectual. Considerando que a atividade de desenvolver um software é intelectual, ela, então, também pode ser classificada como de natureza artística, isto é, depende de pessoas para ser realizada. Portanto desenvolver um software é um processo complexo, intelectual e criativo que apresenta, para cada requisito, diferentes pro- postas de solução e que dependem de pessoas, com diferentes intelectos, para criar e decidir a melhor solução para os problemas apresentados. Nesse contexto, um Processo de Software bem definido garante sistematização, regras, prazos, ferra- mentas e outros procedimentos padronizados que auxiliam as pessoas envolvidas na aplicação do seu intelecto para a produção das ações desejadas para o produto.

Um processo de software deve estabelecer atividades que envolvam todos os aspectos do desenvolvimento, desde a concepção do sistema, ou seja, sua ideia, até suas exceções, aquilo que não será resolvido pelo software, suas funcionali- dades, quais são as responsabilidades e objetivos do produto a ser desenvolvido.

Devem estar definidas as atividades de modelagem do software, em que será feita a interpretação dos requisitos para a produção de uma descrição de todos os componentes que serão necessários para a codificação do software. Acima, denominamos essa fase de projeto de software, projeto aqui, nessa fase, pode ser interpretado como arquitetural, em que técnicas e/ou ferramentas de modela- gem serão utilizadas para produzir a descrição da arquitetura do produto a ser desenvolvido, definição dos módulos e seus relacionamentos, definição da inter- face, como será a interação do produto com o usuário, e organizado, de forma a ser entendível tanto para o cliente quanto para a equipe de desenvolvimento.

Riscos, custos, prazos podem ser definidos nessa fase também.

As atividades de codificação são as próximas a serem contempladas no pro- cesso de software em que serão estabelecidas as iterações e interações, se serão feitos testes nessa fase, como serão tratados os impedimentos e como será exe- cutada a validação do software, por pacotes, ou depois de o produto pronto, ou, ainda, como uma fase anterior à codificação. O processo de software deve con- siderar, também, manutenção do produto desenvolvido, em que, praticamente, todas as fases anteriores são abrangidas quando é determinado o ciclo de manu- tenção. Vale registrar aqui que todas essas informações devem ser consideradas pelo modelo de processo de software, e todas as atividades estão vinculadas ao

(25)

Importância da Engenharia de Requisitos no Processo de Desenvolvimento de Software

Reprodução proibida. Art. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.

23

desenvolvimento do produto final, qual ordem executá-las e quais atividades acrescentar variam para cada modelo de processo de software.

O objetivo desta disciplina é aprofundar o conhecimento na atividade de especificação de software, também conhecida como engenharia de requisitos, as demais atividades do processo de software serão trabalhadas, em momento oportuno, por outras disciplinas.

IMPORTÂNCIA DA ENGENHARIA DE REQUISITOS NO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

A Figura 3 é um clássico na área do desenvolvimento de software. Ela demonstra exata- mente o que acontece durante o processo de levantamento de informações sobre um produto a ser desenvolvido e podemos abstraí-la para a engenharia de requisitos.

No tópico anterior, fala- mos, brevemente, sobre a conferência organizada para tratar dos assuntos relaciona-

dos ao desenvolvimento de software, que ficou conhecida como Crise do Software.

A conferência, que aconteceu em 1968, foi organizada para tratar de assuntos como a complexidade dos problemas do desenvolvimento do software, a ausên- cia de técnicas bem estabelecidas e a crescente demanda por novas aplicações e teve como objetivo estabelecer práticas mais maduras para o processo de desen- volvimento. As causas da crise do software estão ligadas à complexidade do processo de software e à falta de metodologias para tratá-las durante o processo de desenvolvimento, o que promovia, principalmente, os seguintes problemas:

Figura 3: Processo de comunicação durante o desenvolvimento de projeto.

Fonte: Corazzin (online).

(26)

DESCRIÇÃO DE IMAGENS

PÁGINA 23 – Figura 3: Processo de comunicação durante o desenvolvimento de projeto.

INÍCIO DESCRIÇÃO –A imagem apresenta o Processo de comunicação durante o desenvolvimento do projeto. A figura apresenta uma charge com dez quadros, e está organizada da seguinte maneira: cinco quadros na parte superior e cinco na parte inferior.

No primeiro quadro obtemos a ilustração de uma árvore, com um balanço do lado direito da árvore, com três pedaços de tábuas, um sobre o outro, com a seguinte escrita abaixo da ilustração: "Como o cliente explicou".

Já no quadro ao lado, há a mesma árvore, com um balanço, sendo uma corda amarrada em um galho de cada lado da mesma, com uma tábua. Abaixo da ilustração contém "como o GP entendeu".

Logo após, contém a ilustração de uma árvore suspensa com dois galhos apoiando de cada lado fixados aos solo, com o tronco também suspenso, com um balanço amarrado em um galho de cada lado e a tábua do balanço ao meio do tronco suspenso. Abaixo da ilustração há "Como o analista projetou".

Em seguida, a ilustração apresenta uma árvore com o balanço amarrado ao tronco. Sendo

“Como o programador codifica”.

(27)

DESCRIÇÃO DE IMAGENS

Depois, a ilustração apresenta novamente uma árvore e do lado direito há um balaço com uma poltrona em azul, com umas luzes ao fundo em amarelo. Intitulado de "Como o consultor descreveu".

Já na parte inferior da imagem, do lado esquerdo no primeiro quadro há a ilustração de um gramado e um céu com nuvens, com a seguinte informação abaixo, "Como foi documentado".

Em seguida, no quadro ao lado, contém a ilustração de uma árvore com uma corda amarrada a um galho do lado direito, com a seguinte descrição: "O que foi instalado".

Logo após, há a ilustração de uma montanha russa feita em madeira, descrito como "Como foi cobrado".

Já no quadro ao lado, há a ilustração de um gramado com o tronco de uma árvore cortado, com a seguinte descrição: "Como foi suportado".

Por fim, no último quadro há a ilustração de uma árvore novamente com um pneu amarrado com uma corda do lado esquerdo, descrito "O que o cliente realmente queria".

FIM DESCRIÇÃO.

(28)

ENGENHARIA DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE

Reprodução proibida. Art. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.

U N I D A D E I 24

■ Projetos estourando o orçamento.

■ Projetos estourando o prazo.

■ Software de baixa qualidade.

■ Softwares, muitas vezes, não atingiam os requisitos.

■ Projetos não gerenciáveis.

■ Código difícil de manter.

Levanto novamente este assunto para propor uma analogia entre o cenário de desenvolvimento de software em 1968 e o atual. O que mudou?

Negativamente, percebemos que todas as conquistas citadas acima e mais cin- quenta anos de experiência no desenvolvimento de software não bastaram para melhorar efetivamente a qualidade do software. O pmsurvey.org publica, anual- mente, uma pesquisa promovida e organizada pelo Project Management Institute, que conta com a participação de centenas de organizações no mundo. Os resultados da pesquisa de 2012 mostram que cerca de 60% das organizações têm cumprido as metas dos fatores críticos de sucesso, conforme indicado na tabela a seguir.

FATORES CRÍTICOS DE SUCESSO EM PROJETOS

1. Problemas de comunicação. 10. Estimativas incorretas ou sem fundamento.

2. Não cumprimento de prazos. 11. Problemas com fornecedores.

3. Escopo não definido adequadamente. 12. Retrabalho em função da falta de qualidade do produto.

4. Mudanças de escopo constantes. 13. Falta de definição de responsabilidades.

5. Recursos humanos insuficientes. 14. Falta de apoio na alta administração/patrocina- dor.

6. Riscos não avaliados corretamente. 15. Falta de competência para gerenciar projetos 7. Concorrências entre o dia a dia e o

projeto na utilização dos recursos. 16. Falta de uma metodologia de apoio.

8. Mudanças de prioridade constantes

ou falta de prioridade. 17. Falta de uma ferramenta de apoio.

9. Não cumprimento do orçamento

estabelecido. 18. Clientes não satisfeitos.

Tabela 1: Fatores Críticos de Sucesso em Projetos Fonte: Pmsurvey.org (2012).

(29)

DESCRIÇÃO DE IMAGENS

PÁGINA 24 – Tabela 1: Fatores Críticos de Sucesso em Projetos

INÍCIO DESCRIÇÃO –A imagem apresenta uma tabela com os Fatores Críticos de Sucesso em Projetos, nela contém as seguintes informações:

FATORES CRÍTICOS DE SUCESSO EM PROJETOS 1. Problemas de comunicação.

2.Não cumprimento de prazos.

3. Escopo não definido adequadamente.

4. Mudanças de escopo constantes.

5. Recursos humanos insuficientes.

6. Riscos não avaliados corretamente.

7. Concorrências entre o dia a dia e o projeto na utilização dos recursos.

8. Mudanças de prioridade constantes ou falta de prioridade.

9.Não cumprimento do orçamento estabelecido.

10. Estimativas incorretas ou sem fundamento.

11. Problemas com fornecedores.

12. Retrabalho em função da falta de qualidade do produto.

13. Falta de definição de responsabilidades.

14. Falta de apoio na alta administração/patrocinador.

15. Falta de competência para gerenciar projetos 16. Falta de uma metodologia de apoio.

17. Falta de uma ferramenta de apoio.

18. Clientes não satisfeitos. FIM DESCRIÇÃO.

(30)

Importância da Engenharia de Requisitos no Processo de Desenvolvimento de Software

Reprodução proibida. Art. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.

25

O The Standish Group publica, a cada dois anos, uma pesquisa chamada Chaos Report, que aponta o percentual de projetos, na área de TI, que alcançam sucesso, déficit (atraso/prejuízo) ou fracasso. O relatório de 2013 aponta que ape- nas 39% dos projetos de TI no mundo alcançam sucesso.

Positivamente, vários modelos de processo de desenvolvimento de software foram propostos, várias ferramentas para automação das atividades do pro- cesso foram criadas. Artefatos de gerenciamento de projeto de software foram propostos. A gestão de projetos já há algum tempo vem conquistando espaço estratégico nas organizações, como comprovado pelos estudos promovidos pelo Project Management Institute Brasil (PMI), entidade internacional que regula- menta os profissionais do setor.

Temos, ainda, nesse intervalo, o manifesto ágil, uma reunião de dezessete pes- soas em 2001, no The Lodge at Snowbird Resort, que resultou no Manifesto para o desenvolvimento Ágil de Software, o qual estudaremos mais a fundo na unidade V, e, finalmente, o cenário da crescente adoção de modelos de maturidade, como MPS.

BR (Melhoria do Processo de Software Brasileiro), da SOFTEX, e CMMI (Capability Maturity Model Integration), da SEI, é um indicador de que as empresas nacio- nais estão se preocupando com a qualidade dos produtos e serviços que oferecem.

Toda essa conversa foi necessária para dar suporte à afirmação que farei a seguir: o principal causador de falhas dos projetos de software são falhas no pro- cesso de Engenharia de Requisitos.

Considere comigo: tudo – especificação, projeto, modelagem, programação, testes, implantação, manutenção - parte do entendimento e da determinação de

“o que se pretende fazer”. O descompromisso com essa determinação causa incre- mentos não desejados, como: atrasos no cronograma, custos acima do previsto, falta de recursos humanos, alteração dos requisitos, alteração das especificações, flexibilização comprometedora do escopo, qualidade abaixo da esperada, frus- tração do cliente e outros tantos problemas.

Outro recurso que utilizo para ilustrar a importância da Engenharia de Requisitos no processo de desenvolvimento de software são os estudos pro- movidos pelo Standish Group. Eles mostram que o alto índice de manutenção, retrabalho em nível de requisitos, projeto, codificação, testes é causado por falhas de definição nas fases iniciais do processo de desenvolvimento.

(31)

ENGENHARIA DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE

Reprodução proibida. Art. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.

U N I D A D E I 26

% DO CUSTO DE

DESENVOLVIMENTO % DOS ERROS

INTRODUZIDOS % DOS ERROS

ENCONTRADOS CUSTO RELATIVO DE CORREÇÃO Análise de

Requisitos 5 55 18 1

Projeto 25 30 10 1 ~ 1,5

Codificação e teste de unidade 50

Teste 10 10 50 1 ~ 5

Validação e do- cumentação 10

manutenção 5 22 10 ~ 100

Tabela 2: Levantamento de custos com erros nas fases de projetos de software Fonte: Standish Group – CHAOS Report 2013 on software project success and failure.

O que a Tabela 2 nos aponta é, primeiramente, que os custos relacionados à análise de requisitos são baixos, nessa fase, a maioria dos erros é apresentada. Observe que, se os erros apresentados fossem corrigidos nessa fase, os custos de correção ficariam baixíssimos, enquanto, se deixarmos para corrigi-los depois da validação, lá na fase da manutenção (última linha da tabela), os custos aumentariam exorbitantemente.

O mesmo estudo apresenta fatores críticos para o sucesso dos projetos de software. Os dez mais lembrados estão relacionados na tabela a seguir. Observe que três principais fatores para o sucesso estão relacionados às atividades da Engenharia de Requisitos: requisitos incompletos, falta de envolvimento do usu- ário, mudança de requisitos e especificações.

FATORES CRÍTICOS PARA O SUCESSO DE PROJETOS DE SOFTWARE

Fatores Porcentagem

Requisitos Incompletos 13,1

Falta de Envolvimento do Usuário 12,4

Falta de Recursos 10,6

Expectativas Irreais 9,9

Falta de apoio Executivo 9,3

Mudança de Requisitos e Especificações 8,7

Falta de Planejamento 8,1

Sistema não mais necessário 7,5

Tabela 3: Fatores Críticos para o Sucesso de Projetos de Software

Fonte: Standish Group – CHAOS Report 2013 on software project success and failure.

(32)

DESCRIÇÃO DE IMAGENS

PÁGINA 26 – Tabela 2: Levantamento de custos com erros nas fases de projetos de software

INÍCIO DESCRIÇÃO – A imagem apresenta uma tabela com os Levantamento de custos com erros nas fases de projetos de software, com quatro colunas sendo "% DO CUSTO DE DESENVOLVIMENTO, % DOS ERROS INTRODUZIDOS, % DOS ERROS ENCONTRADOS e CUSTO RELATIVO DE CORREÇÃO", e seis linhas, contendo as seguintes informações:

% DO CUSTO DE DESENVOLVIMENTO Análise de Requisitos: 5

Projeto: 25

Codificação e teste de unidade: 50 Teste: 10

Validação e documentação: 10

% DOS ERROS INTRODUZIDOS Análise de Requisitos: 55 Projeto: 30

Teste: 10 manutenção: 5

% DOS ERROS ENCONTRADOS Análise de Requisitos: 18 Projeto: 10

Teste: 50 manutenção: 22

(33)

DESCRIÇÃO DE IMAGENS

CUSTO RELATIVO DE CORREÇÃO Análise de Requisitos: 1

Projeto: 1~1,5 Teste: 1~ 5

manutenção: 10~100 FIM DESCRIÇÃO.

(34)

DESCRIÇÃO DE IMAGENS

PÁGINA 26 – Tabela 3: Fatores Críticos para o Sucesso de Projetos de Software

INÍCIO DESCRIÇÃO –A imagem apresenta uma tabela com os Fatores Críticos para o Sucesso de Projetos de Software, com duas colunas intituladas de "Fatores e Porcentagem", com oito linhas, contendo as seguintes informações:

FATORES CRÍTICOS PARA O SUCESSO DE PROJETOS DE SOFTWARE Fatores: Requisitos Incompletos, Porcentagem: 13,1

Fatores: Falta de Envolvimento do Usuário, Porcentagem: 12,4 Fatores: Falta de Recursos, Porcentagem: 10,6

Fatores: Expectativas Irreais, Porcentagem: 9,9 Fatores: Falta de apoio Executivo, Porcentagem: 9,3

Fatores: Mudança de Requisitos e Especificações, Porcentagem: 8,7 Fatores: Falta de Planejamento, Porcentagem: 8,1

Fatores: Sistema não mais necessário, Porcentagem: 7,5 FIM DESCRIÇÃO.

(35)

Considerações Finais

Reprodução proibida. Art. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.

27

Será que alcancei meu objetivo de convencê-lo sobre a importância da Engenharia de Requisitos no processo de produção de um software? É palpável que o trabalho mais criterioso na fase inicial do processo de software garante o sucesso de todo o projeto.

Encerro o assunto citando Pressman (2010, p. 117): “engenharia de requisi- tos estabelece uma base sólida para o projeto e a construção. Sem ela o software resultante tem uma alta probabilidade de não satisfazer as necessidades do cliente”.

Isto é, o entendimento do “o que fazer” para sua catalogação e modelagem efi- ciente representará a real necessidade do cliente, que se trata do ponto-chave para a qualidade do software.

CONSIDERAÇÕES FINAIS

Nesta unidade, revisamos alguns conceitos básicos que você, talvez, já tenha conhecido na sua formação. Este nivelamento foi necessário para podermos situar a engenharia de requisitos nas atividades da engenharia de software.

Definimos que a engenharia de software é uma abordagem sistemática que envolverá todos os aspectos de desenvolvimento do software: o projeto, a análise e a construção do software para algum objetivo específico. Formulamos, juntos, a definição de processo como uma atividade organizada em etapas específicas a serem desenvolvidas de forma contínua, que mantenha uma unidade, a fim de alcançar um propósito final, que é um produto de software de qualidade. Sendo

Há mais de quarenta anos, a engenharia de software nos apresenta a im- portância da fase de levantamento e análise dos requisitos, para o desen- volvimento de software, pesquisas renomadas comprovam que um levan- tamento mal executado é a principal causa dos estouros nos projetos de desenvolvimento de software, porque, ainda hoje, enfrentamos esses mes- mos problemas?

Fonte: Galeote (online).

(36)

ENGENHARIA DE REQUISITOS NO CONTEXTO DA ENGENHARIA DE SOFTWARE

Reprodução proibida. Art. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.

U N I D A D E I 28

assim, o processo de software representa um conjunto de atividades que nos orienta durante o desenvolvimento do software.

O CMMI (Capability Maturity Model Integration) é um modelo de capa- citação de processos de software, desenvolvido pelo SEI (Software Engineering Institute) e patrocinado pelo Departamento de Defesa Americano (DoD), para a avaliação da capacidade das fábricas de software de repetir uma série de resulta- dos de uma maneira previsível e com qualidade. Como profissionais da área de desenvolvimento de software, é muito importante entender como os conceitos se encaixam na prática, o que o CMMI e outros modelos de maturidade bus- cam é avaliar a qualidade de gestão de processos das empresas desenvolvedoras de software, então, percebemos que, para produzir um produto de qualidade, dependemos da qualidade de seu processo de desenvolvimento, que está inti- mamente ligado com o processo da engenharia de requisitos.

Lembre-se de que não existe um processo ideal, deve ser estabelecido um conjunto de atividades específicas para cada projeto e, ainda que dentro de uma mesma empresa, para cada projeto, deve ser estabelecido seu próprio processo, considerando suas exigências e realidade comercial.

(37)

29

1. A definição “é a abordagem sistemática que envolverá todos os aspectos de de- senvolvimento do software: o projeto, a análise e a construção do software para algum objetivo específico” diz respeito a:

a. Processo de software.

b. Engenharia de software.

c. Software.

d. Engenharia de requisitos.

2. Assinale a alternativa correta sobre Processo de Software:

I. Conjunto de atividades bem definidas, com responsáveis, com artefatos de entrada e saída, com dependências entre elas e ordem de execução, com mo- delo de ciclo de vida.

II. Conjunto parcialmente ordenado de atividades (ou passos) para se atingir um objetivo, definindo quem está fazendo o que, quando e como para atingir um certo objetivo.

III. O processo de software é um conjunto de atividades que nos orienta durante o desenvolvimento do software. Um processo irá determinar as responsabili- dades de cada um dos envolvidos, o prazo e quais ferramentas serão utiliza- das.

a. Apenas I está correta.

b. Apenas II está correta.

c. Apenas III estão corretas.

d. I, II e III estão corretas.

3. “Um modelo de processo de software é um conjunto de métodos e ferramentas orientados para auxiliar no planejamento, desenvolvimento, controle e manu- tenção de um software”. Sobre modelo de processo de software, analise as alter- nativas abaixo:

I. Não existe um processo ideal, a maioria das organizações desenvolve os pró- prios processos de desenvolvimento de software.

II. Um modelo de processo de software é uma descrição simplificada do proces- so de desenvolvimento de software.

III. Os modelos de processo de software incluem as atividades, que fazem parte do processo de desenvolvimento de software.

(38)

a. Apenas I está correta.

b. Apenas I e III estão corretas.

c. Apenas II e III estão corretas.

d. I, II e III estão corretas

4. “Um arcabouço de processo estabelece o alicerce para um processo de software completo pela identificação de um pequeno número de atividades aplicáveis a todos os projetos de software, independentemente de seu tamanho ou com- plexidade”. Essa é a definição de Pressman (2010) para Processo de Software. Em relação a Processo de Software, qual alternativa abaixo está correta?

a. A atividade especificação de software: define as funcionalidades que deverão ser desenvolvidas para que se obtenha como produto final o software espe- cificado pelo cliente.

b. A atividade de projeto de software: define a funcionalidade do software e as restrições sobre sua operação.

c. A atividade de validação de software: o software deve ser reescrito e mantido para garantir que faça o que o cliente deseja.

d. Evolução de software: o software deve evoluir para atender aos novos requi- sitos que, naturalmente, surgirão.

5. Os estudos promovidos pelo Standish Group mostram que o alto índice de ma- nutenção, retrabalho em nível de requisitos, projeto, codificação, testes é cau- sado por falhas de definição nas fases iniciais do processo de desenvolvimento.

Selecione a alternativa que relaciona uma atividade inicial, em um processo de software:

a. Levantamento de requisitos.

b. Teste de software.

c. Programação.

d. Implantação.

(39)

31

DESENVOLVIMENTO DE SOFTWARE REQUER PROCESSO DE GESTAO.

Software, de modo genérico, é uma enti- dade que se encontra em quase constante estado de mudança. Essas mudanças ocor- rem por necessidade de corrigir erros existentes no software e/ou de adicionar novos recursos e funcionalidades. Igual- mente, os sistemas computacionais (isto é, aqueles que têm software como um de seus principais elementos) também sofrem mudanças freqüentemente. Essa necessi- dade evolutiva do sistema de software o torna predisposto a defeitos (isto é ‘não confiável’), podendo resultar em atraso na entrega e em custos acima do estimado.

Concomitante com esses fatos, o cresci- mento em tamanho e complexidade dos sistemas de software exige que os pro- fissionais da área raciocinem, projetem, codifiquem e se comuniquem por meio de componentes (de software) e qualquer con- cepção ou solução de sistema passa então para o nível arquitetural. Nesse sentido, o objetivo deste artigo é discutir e explorar o fato de que software não é construído como uma TV ou geladeira, mas desenvolvido.

Quase cinco décadas atrás software consti- tuía uma insignificante parte dos sistemas existentes e seu custo de desenvolvimento e manutenção eram desprezíveis. Para per- ceber isso, basta olharmos para história da indústria do software (www.softwarehis- tory.org). Encontra-se o uso do software numa ampla variedade de aplicações tais como sistemas de manufatura, software científico, software embarcado, robótica

e aplicações Web, dentre tantas. Paralela- mente, observou-se o surgimento de várias técnicas de modelagem e projeto bem como de linguagens de programação. Per- ceba que o cenário existente, décadas atrás, mudou completamente. Antigamente, os projetos de sistemas alocavam pequena parcela ao software. Os componentes de hardware, diferentemente, eram analisa- dos e testados quase exaustivamente o que permitia a produção rápida de grandes quantidades de subsistemas e implicava em raros erros de projetos. Entretanto, a facilidade inicial de modificar o software, comparativamente ao hardware, motivou seu uso. A intensificação do uso do software numa larga variedade de aplicações o fez crescer em tamanho e complexidade. Isto tornou proibitivo analisar e testar exaus- tivamente, além de impactar no custo de manutenção.

Perceba que à medida que tamanho e complexidade dos sistemas de software aumentam, o problema de projeto extra- pola as estruturas de dados e algoritmos de computação. Ou seja, há necessidade de considerar o projeto da arquitetura (ou estrutura geral) do sistema, exigindo tam- bém um processo de desenvolvimento de software. O ciclo de vida de um produto compreende um conjunto de atividades que vai desde sua concepção até a entrega desse produto ao cliente, envolvendo ainda sua evolução e, eventualmente, retirada desse produto.

Fonte: Filho (2011, online).

(40)

MATERIAL COMPLEMENTAR

Engenharia de Software - Uma Abordagem Profissional Roger S. Pressman

Editora: Bookman

Sinopse: Versão concebida tanto para alunos de graduação quanto para profissionais da área. Oferece uma abordagem contemporânea sobre produção do software, gestão da qualidade, gerenciamento de projetos, com didática eficiente e exercícios de grande aplicação prática.

(41)

UNIDADE

II

Professora Me. Vanessa Ravazzi Perseguine

FUNDAMENTOS DA ENGENHARIA DE REQUISITOS

Objetivos de Aprendizagem

■ Conhecer os fundamentos da engenharia de requisitos e definir seus principais artefatos de saída.

■ Entender a importância da engenharia de requisitos no contexto de desenvolvimento de software.

Plano de Estudo

A seguir, apresentam-se os tópicos que você estudará nesta unidade:

■ Conceitos fundamentais da engenharia de requisitos

Stakeholders

■ Classificação dos requisitos

■ Documentação dos requisitos de software

■ Template documento de requisitos

■ Matriz de rastreabilidade de requisitos

■ Template matriz de rastreabilidade de requisitos

(42)
(43)

INTRODUÇÃO

Olá! Vamos para mais uma unidade de estudos? Avançando em nosso aprendi- zado, estudaremos os conceitos fundamentais da engenharia de requisitos. Não é possível entender o propósito de uma atividade sem, primeiro, compreender os elementos que a compõem.

O primeiro elemento que devemos dominar seu significado é requi- sitos. Todo nosso curso baseia-se nele. Entender do que se trata e como ele deve ser tratado é crucial para o sucesso da engenharia de requisitos.

Observaremos, no decorrer da unidade, que os requisitos delimitam o sof- tware, pois estabelecem as funcionalidades e as restrições solicitadas por um conjunto de stakeholders. O processo de especificação e documentação de requisitos é fundamental para o sucesso de um projeto de software e enten- deremos que um bom documento de requisitos possibilita estimativas de custos mais precisas, cronogramas mais ajustados e um produto final que atende às expectativas do cliente.

Outro elemento importante na engenharia de requisitos é o stakeholder.

Os requisitos de software são levantados e mapeados por meio da análise dos stakeholders. Como cada grupo de stakeholder tem interesses específicos e par- ticulares, eles podem, ao invés de colaborar, atrapalhar o desenvolvimento do software, se não forem bem gerenciados. Nesta unidade, conheceremos o que significa stakeholders e entenderemos o tipo de influência que eles podem cau- sar ao projeto de desenvolvimento de software.

O objetivo desta unidade, além de garantir o conhecimento sobre os prin- cipais elementos da engenharia de requisitos, é assimilar o que foi apresentado na unidade anterior sobre a importância da engenharia de requisitos enquanto principal causadora de falhas dos projetos de software.

Boa leitura!

Introdução

Reprodução proibida. Art. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.

35

(44)

FUNDAMENTOS DA ENGENHARIA DE REQUISITOS

Reprodução proibida. Art. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.

U N I D A D E II 36

CONCEITOS FUNDAMENTAIS DA ENGENHARIA DE REQUISITOS

A engenharia de requisitos, segundo Sommerville (2008), envolve todas as ativida- des de conceituação, documentação e manutenção de um conjunto de requisitos para um sistema baseado em computador.

Vamos observar o significado das palavras em separado:

■ Engenharia1- substantivo feminino: aplicação de métodos científicos ou empíricos à utilização dos recursos da natureza em benefício do ser humano

■ Requisito2- adjetivo: 1. p.us. que foi requisitado, requerido; 2. substantivo masculino: condição para se alcançar determinado fim

Juntado os conceitos: engenharia de requisitos pode ser definida, então, como conjunto de atividades sistemáticas como condição para se alcançar determi- nado fim, o que se foi requisitado. Nesse sentido, Sommerville (2003, p. 103) nos positiva com sua definição: “engenharia de requisitos é um processo que envolve todas as atividades exigidas para criar e manter o documento de requi- sitos de sistema”.

“Conjunto de atividades” pode ser entendido como “processo”, e sobre pro- cesso, nós entendemos! Assim, o propósito da engenharia de requisitos está relacionado com a identificação de metas a serem atingidas: qualidade de sof- tware; produtividade no desenvolvimento, operação e manutenção de software;

permitir que profissionais tenham controle sobre o desenvolvimento de software dentro de custos, prazos e níveis de qualidade desejados.

1 Resultado da busca pelo termo “defina engenharia” no Google.

2 Resultado da busca pelo termo “defina requisito” no Google.

Referências

Documentos relacionados

• El programa de lavado se detiene con el agua en el tambor. El tambor gira regularmente para evitar arrugas en las prendas... • La puerta permanece bloqueada. Debe drenar el agua

Di fatto, celebrare l’Avvento è accogliere i segni della venuta del Regno Divino nella nostra vita, come un’apertura alla Novità che trasforma la realtà del mondo e del

O mecanismo de ação dos cremes à base de Casearia sylvestris ainda não é conhecido e futuros estudos serão necessários para entender o mecanismo, foi possível observar (Figuras 9

Deste modo optamos por utilizar, a plataforma do GOOGLE DOCS ® por ser um software de uso livre e atender perfeitamente nossas necessidades; através da qual foi montado um

Luminosidade de cidade, ao final do dia Ruído da cidade Rato do campo Rato da cidade Som ambiente 12 7. Decisão de regresso

Parte 2: Ligantes hidráulicos de endurecimento normal para estradas – Composição, especificações e critérios de conformidade.. Composição, especificações e critérios

- Elaborar um diagnóstico que permita fazer um levantamento das condições naturais e socioeconômicas dos agricultores familiares da Adessu e do assentamento Chico Mendes III

condições perigosas ou indesejáveis do sistema, e iniciar manobras convenientes de chaveamento ou dar aviso Segundo a ABNT, o relé é um dispositivo pôr meio do qual um