ES - Engenharia de Software I

ENGENHARIA DE SOFTWARE I

Engenharia de software.indd 1Engenharia de software.indd 1 18/7/2013 17:51:0518/7/2013 17:51:05Process BlackProcess Black

Obra organizada pela Universidade Luterana do Brasil. Informamos que de inteira responsabilidade dos autores a emisso de conceitos.

Nenhuma parte desta publicao poder ser reproduzida por qualquer meio ou forma sem a prvia autorizao da Editora da ULBRA.

A violao dos direitos autorais crime estabelecido na Lei n .610/98 e punido pelo Artigo 184 do Cdigo Penal.

Conselho Editorial EADDris Cristina GedratThomas HeimmanMara Salazar MachadoAndra de Azevedo EickAstomiro Romais

Setor de Processamento Tcnico da Biblioteca Martinho Lutero - ULBRA/Canoas

Dados Internacionais de Catalogao na Publicao (CIP)

G216e Garcia, Lus Fernando Fortes. Engenharia de soft ware I / Lus Fernando Fortes Garcia. Canoas: Ed. ULBRA, 2013. 104p.

1. Computao. 2. Engenharia de soft ware. 3. Projeto e arquitetura de soft ware. I. Ttulo.

CDU: 681.3.41

Editorao: Roseli Menzen

Dados tcnicos do livroFontes: Palatino Linotype, Franklin Gothic Demi CondPapel: o set 75g (miolo) e supremo 240g (capa)Medidas: 15x22cm

ISBN 978-85-7528-490-2


APRESENTAO

Prezados(a) alunos(a),

Sejam bem vindos(as) a disciplina de Engenharia de Software I.

Esta disciplina apresenta a proposta da rea de Engenharia de Software para estruturao e organizao do processo de desenvolvimento de software, bem como a sua rea coirm de Qualidade de Software.

Visa abordar e analisar os principais tpicos relacionados a desenvolvimento profissional de software, contribuindo para a discusso dos pontos positivos e negativos de cada conceito.

O objetivo principal da disciplina disseminar o conceito de respeito ao software, isto , software atualmente importante demais na sociedade para ser desenvolvido de forma artesanal, sem cuidados e projetos. As consequncias de um desenvolvimento desleixado so terrveis em termos de perdas em vidas humanas e perdas financeiras!

So abordados, na parte de Engenharia de Software, conceitos de Processos de Software, de Engenharia de Requisitos, de Projeto e Arquitetura de Software, Testes de Software e evoluo/Sistemas Legados.

Na segunda parte do texto, em Qualidade de Software, so apresentados conceitos relacionados a Qualidade, Qualidade de Software em seus dois aspectos Qualidade de Produtos de Software e Qualidade de Processos de Software, bem como discutidos os modelos de Maturidade em Qualidade de Softwares, representados pelo CMMI e pelo MPS.BR.

Todos os tpicos aqui discutidos tm aplicabilidade na vida prtica de um profissional de desenvolvimento de software, seja ele um programador, um analista, um arquiteto ou um testador. O sucesso do processo dado pela integrao correta e juno de esforos de todos estes profissionais, em conjunto com os clientes/usurios.


A Engenharia de Software est em constante atualizao e redesenho os Mtodos geis so um dos exemplos mais claros disso. O estudo continuado da rea imprescindvel para o seu sucesso profissional!

Um bom trabalho a todos!

Prof. Dr. Lus Fernando Fortes Garcia

Professor/pesquisador na ULBRA/Canoas e Faculdade Dom Bosco de Porto Alegre

Consultor em Carreiras de TI na ofiTIo Consultoria Ltda.


SOBRE O AUTOR

Lus Fernando Fortes Garcia, prof. Dr.

Doutor e mestre em Cincias da Computao pelo Instituto de Informtica da UFRGS Universidade Federal do Rio Grande do Sul. Professor universitrio e pesquisador nas reas de Engenharia de Software, Qualidade de de Software e Governana de TI na ULBRA e Faculdade Dom Bosco de Porto Alegre.

Scio-diretor e consultor em carreiras de TI na ofoTIo consultoria Ltda.


6ULBR

A E

duca

o a

Dist

nci

a


SUMRIO

1 INTRODUO ENGENHARIA DE SOFTWARE .............................................................11

1.1 Computadores e Software .................................................................................11

1.2 Evoluo Histrica do Software ..........................................................................12

1.3 Questes sobre Desenvolvimento de Software .....................................................13

1.4 Enfoques do Desenvolvimento de Software ..........................................................14

1.5 Engenharia de Software .....................................................................................15

1.6 Pirmide da Engenharia de Software ..................................................................17

1.7 Princpios da Engenharia de Software .................................................................18

1.8 Qualidades Desejveis em um Software ..............................................................19

Atividades .............................................................................................................20

2 PROCESSOS DE SOFTWARE......................................................................................23

2.1 Processos e Software ........................................................................................23

2.2 Modelos de Processos de Software .....................................................................24

2.3 Modelo Cascata ................................................................................................24

2.4 Modelo Evolutivo ou Evolucionrio ......................................................................28

2.5 Modelo Iterativo Incremental ...........................................................................29

2.6 Modelo Baseado em Componentes .....................................................................30

2.7 Modelo RUP Rational Unifi ed Process .............................................................31

Atividades .............................................................................................................32

3 PROCESSO GEIS DE SOFTWARE ..............................................................................33

3.1 Processos geis de Software .............................................................................33

3.2 XP Extreme Programming ................................................................................37

3.3 SCRUM .............................................................................................................39

Atividades .............................................................................................................42

4 ENGENHARIA DE REQUISITOS ..................................................................................43

4.1 Engenharia de Requisitos ..................................................................................43


4.2 Defi nies de Requisito .....................................................................................45

4.3 Tipos de Requisitos ............................................................................................45

4.4 Processo da Engenharia de Requisitos ................................................................47

Atividades .............................................................................................................51

5 PROJETO E ARQUITETURA DE SOFTWARE ..................................................................53

5.1 Projeto e Arquitetura de Software ......................................................................53

5.2 Arquitetura de Sistema .....................................................................................53

5.3 Soluo Tcnica ................................................................................................55

5.4 Reuso em Projeto e Arquitetura de Software........................................................56

Atividades .............................................................................................................58

6 TESTE DE SOFTWARE ...............................................................................................61

6.1 Contexto atual do Teste de Software ..................................................................61

6.2 Defi nio de Teste de Software ..........................................................................62

6.3 Provveis defeitos e tipos de falhas ....................................................................63

6.4 Processo de Teste de Software ...........................................................................64

6.5 Classifi cao dos Teste de Software ...................................................................64

6.6 Tcnicas de Teste de Software ............................................................................65

Atividades .............................................................................................................66

7 EVOLUO de software ............................................................................................67

7.1 Evoluo de Software .........................................................................................67

7.2 Sistemas Legados ..............................................................................................67

7.3 Estratgias em Sistemas Legados .......................................................................69

Atividades .............................................................................................................71

8 QUALIDADE .............................................................................................................73

8.1 Motivaes no estudo da Qualidade ....................................................................73

8.2 Histrico da Qualidade ......................................................................................74

8.3 Defi nies da Qualidade ....................................................................................75

8.4 Princpios de Qualidade de Deming .....................................................................76

8.5 Ferramentas da Qualidade .................................................................................78

8.6 rgos de Certifi cao da Qualidade ..................................................................78

8.7 Fatores Humanos na Qualidade ..........................................................................79

8.8 5S na Qualidade ................................................................................................79

Atividades .............................................................................................................80


9 QUALIDADE DE SOFTWARE .......................................................................................81

9.1 Software ...........................................................................................................81

9.2 Qualidade de Software .......................................................................................82

9.3 Fatores da Qualidade de Software ......................................................................83

9.4 Aspectos da Qualidade de Software ....................................................................84

9.5 Normas da Qualidade de Software ......................................................................85

9.6 Enfoques da Qualidade de Software ....................................................................85

Atividades .............................................................................................................89

10 MATURIDADE EM QUALIDADE DE SOFTWARE ............................................................91

10.1 Maturidade em Qualidade de Software .............................................................91

10.2 CMMI .............................................................................................................92

10.3 Nveis do CMMI ...............................................................................................93

10.4 reas Chave do CMMI ......................................................................................96

10.5 Representaes do CMMI ................................................................................97

10.6 Processo de implantao do CMMI ...................................................................98

10.7 SCAMPI avaliao do CMMI...........................................................................98

10.8 MPS.BR ..........................................................................................................98

Atividades ...........................................................................................................101


10

ULBR

A E

duca

o a

Dist

nci

a


1 INTRODUO ENGENHARIADE SOFTWARELus Fernando Fortes Garcia, prof. Dr.

Este captulo apresenta a grande rea da Engenharia de Software, seu histrico junto aos desenvolvedores de software ao longo do tempo, alguns questes bsicas que devem ser consideradas em todos os momentos pelos profissionais, suas definies, etapas, focos (pirmide da Engenharia de Software), bem como seus princpios e qualidades desejveis.

O principal objetivo deste captulo apresentar a Engenharia de Software como uma alternativa prtica e adequada ao correto desenvolvimento de produtos de software, com o devido respeito que estes produtos de software merecem.

1.1 Computadores e Software Atualmente tem-se a total e completa onipresena dos computadores e consequentemente do software em nossas vidas. Eles esto em forma de computadores de mesa, servidores, notebooks, smartphones, tablets e mesmo embarcados/embutidos nos mais diferentes aparelhos, desde geladeiras at em um automvel. Sem eles, no podemos fazer uma ligao telefnica, acender uma simples lmpada, fazer transaes financeiras, viajar de avio, entre outras coisas do cotidiano.

Esses mesmos softwares podem ser considerados abstratos, intangveis, complicados, diferentes, complexos e sem limitaes. Visto que no so regidos pelas leis da fsica, a princpio no h limites em seu desenvolvimento. A ausncia de limites, entretanto, fator complicador extremo para seu desenvolvimento.


12

ULBR

A E

duca

o a

Dist

nci

a importante ressaltar os inmeros aspectos positivos dos softwares em nossa sociedade, como aumento de produtividade de uma empresa, velocidade de processamento de dados e economia de tempo, entre outros. Entretanto quando h falhas e bugs existem problemas ou aspectos negativos que no podem ser ignorados:

Quedas de avies;

Desvios de msseis;

Colapsos em centrais telefnicas;

Desvios bancrios.

Para tornar, ento, o software mais confivel, robusto e eficaz, prope-se o estudo e a aplicao da Engenharia de Software.

1.2 Evoluo Histrica do SoftwarePara fins de avaliao histrica do software, de seus tipos e de seus processos de desenvolvimento, pode-se classific-los em 4 grandes geraes. Cada avano de gerao agrega complexidade e aumento de demanda por software.

1. Gerao 1950 a 1960 Soft ware para sistemas computacionais de grande porte (Mainframes) com orientao de processamento em lotes (batch), com distribuio limitada apenas a grandes empresas;

2. Gerao 1960 a 1975 Soft ware para sistemas de mdio porte, com suporte a acessos multiusurios, de tempo real, e bancos de dados. Nesta gerao, inicia-se o acesso a soft wares por empresas de menor porte;

3. Gerao 1975 a 1990 Soft ware para computadores de pequeno porte microcomputadores ligados em redes locais. Incio da utilizao por pessoas fsicas e pequenas empresas, o que aumentou grandemente a demanda;

4. Gerao 1990 a atual Soft wares distribudos em todas as reas da sociedade, extremamente poderosos e complexos (sistemas inteligentes, distribudos, paralelos), rodando em todos os tipos de dispositivos. Chega-se ao pico da complexidade e da demanda.

importante ressaltar que a evoluo no para nesta 4. Gerao novas pesquisas e desenvolvimentos esto sendo realizados em empresas e centros de pesquisa espalhados por todo o mundo. Estes novos softwares esto cada vez mais complexos e teis, e por isso precisam ser desenvolvidos com processos produtivos e controlados.


13

ULBR

A E

duca

o a

Dist

nci

a1.3 Questes sobre Desenvolvimento de SoftwareO processo de desenvolvimento de software suscita algumas importantes questes e sua discusso necessria:

Software desenvolvido, no fabricado Software, diferentemente de outros produtos, como celulares e sapatos, normalmente desenvolvido sob encomenda para clientes e aplicaes especfi cas. Cada soft ware tende a ser, em menor ou maior grau, diferente dos demais. Isso impede que tcnicas de fabricao em escala (industriais) possam ser utilizadas em seu desenvolvimento, que poderiam diminuir custos e prazos;

Soft ware no desgasta Soft ware, ao contrrio do hardware em que se pode facilmente perceber o desgaste de peas e engrenagens no desgasta no sentido literal da palavra. Entretanto, instalaes de soft ware desgastam ao longo do tempo, e, portanto, necessitam de manuteno e de reparos. Um exemplo clssico a instalao de um sistema operacional em um microcomputador; No incio, tem-se velocidade e estabilidade, mas, com o passar do tempo (e pela instalao e desinstalao de programas, jogos, etc) a velocidade do sistema cai e os problemas aparecem, como apresentado na fi gura 1.1.

Figura 1.1 Desgaste em Software.

Tempo

Indice de

falhas

Mortalidade infantil

Desgaste

Natureza mutvel do soft ware Esta uma questo central no desenvolvimento de soft ware. Ao contrrio de outros produtos, em que as mudanas so raras e, quando existem, so implementadas somente aps exaustivas discusses e projetos/simulaes como em prdios, estradas e automveis o soft ware apresenta demandas de alteraes constantes, muitas vezes dirias. Estas alteraes partem tanto dos clientes, que precisam acompanhar o mercado, quanto dos governos e rgos de regulao, em formas de novas leis, novos clculos de impostos e taxas. Portanto raramente pode-se considerar o desenvolvimento de um soft ware concludo.


14

ULBR

A E

duca

o a

Dist

nci

a Uma conferncia da OTAN (Organizao do Tratado do Atlntico Norte) entre 1968 e 1969 cunhou o termo Crise de Software, ao discutir e apresentar questes, na poca, relacionadas ao desenvolvimento de softwares:

Cronogramas no observados atrasos constantes;

Projetos abandonados;

Mdulos que no operam corretamente quando combinados;

Programas que no fazem exatamente o que era esperado;

Sistemas to difceis de usar e que so descartados;

Sistemas que simplesmente param de funcionar.

importante refletir que passados mais de 40 anos muitos (a maioria) desses problemas apresentados continuam a existir.

1.4 Enfoques do Desenvolvimento de SoftwareO desenvolvimento de software pode ser dividido em dois enfoques:

Artesanal;

Engenharia de Soft ware.

O desenvolvimento Artesanal (tambm conhecido por Gambiarra, P.O.G e outros) baseia-se exclusivamente em habilidades pessoais do desenvolvedor para a construo do software. Apresenta um processo bastante simplificado, em que normalmente, aps uma breve conversa do programador com o cliente para a obteno dos requisitos, iniciada a programao, sem etapas importantes, como anlise, projeto e testes. Implementa uma tcnica conhecida como tentativa e erro.

um processo que, apesar de funcionar em alguns casos, muito arriscado para os padres atuais da indstria de software. Tom de Marco, um dos precursores da Engenharia de Software, afirma que na falta de padres expressivos, uma nova indstria, como a de software, passa a depender de folclore.

O desenvolvimento baseado em Engenharia de Software, por sua vez, apresenta uma abordagem mais sistemtica, produtiva, econmica e organizada do processo de desenvolvimento, com a aplicao de etapas bem definidas, com documentao e acompanhamento por profissionais habilitados e especializados em suas tarefas, sendo estas relacionadas a requisitos, anlise, projeto, programao, testes e implantao.


15

ULBR

A E

duca

o a

Dist

nci

a1.5 Engenharia de SoftwareA primeira definio da Engenharia de Software descreve-a como: Estabelecimento e uso de slidos princpios de engenharia para que se possa obter economicamente um software que seja confivel e que funcione eficientemente em mquinas reais, por Fritz Bauer, em 1969.

Esta definio muito relevante, porque destaca claramente os aspectos mais importantes da Engenharia de Software:

Estabelecimento e uso - Ou seja, no adianta defi nir e estabelecer regras e processos, mas sim, necessrio seu efetivo uso para a obteno das vantagens da Engenharia de Soft ware;

Slidos princpios de engenharia - desenvolvimento de soft ware baseado nos mesmos princpios das engenharias tradicionais civil, eltrica que incluem projetos, clculos, simulaes e testes;

Se possa obter economicamente Apresenta o maior fator motivador da implantao da Engenharia de Soft ware o econmico. O objetivo fi nal da Engenharia de Soft ware produzir produtos com mais qualidade, com mais produtividade, visando o lucro do desenvolvedor;

Que seja confi vel No contexto atual da sociedade, este fator indispensvel para a sobrevivncia de um soft ware no mercado. Produtos no confi veis so rapidamente descartados pelos usurios.

O SEI (Instituto de Engenharia de Software da Universidade Carnegie Mellon, USA) define que Engenharia a aplicao sistemtica de conhecimentos cientficos na criao e construo de solues com um bom custo-benefcio para a resoluo de problemas prticos da sociedade.

O IEEE (Instituto de Engenheiros Eletricistas e Eletrnicos, dos Estados Unidos) define a Engenharia de Software como: Aplicao de uma abordagem sistemtica, disciplinada e quantificvel para o desenvolvimento, operao e manuteno do software.

O IEEE edita o SWEBOK (Guide to the Software Engineering Body of Knowledge), que o corpo de conhecimento que apresenta de forma completa a Engenharia de Software, suas reas de conhecimento e as suas disciplinas relacionadas.

As reas da Engenharia de Software, segundo o SWEBOK, so:

Requisitos de soft ware;

Projeto de soft ware;

Construo de soft ware;


16

ULBR

A E

duca

o a

Dist

nci

a Teste de soft ware;

Manuteno de soft ware;

Gerenciamento de confi gurao de soft ware;

Gerenciamento de engenharia de soft ware;

Processo de engenharia de soft ware;

Ferramentas e mtodos da engenharia de soft ware;

Qualidade de soft ware.

A rea de Requisitos de Software aborda a elicitao, anlise, especificao e validao de requisitos de software.

Projeto de Software definido como o processo de definio da arquitetura, componentes, interfaces e outras caractersticas de um sistema ou componente, assim como o resultado desse processo.

Construo de software se refere criao detalhada de software relevante e funcional a partir de uma combinao de codificao, verificao, teste unitrio, teste integrado e debugging.

Teste de software consiste numa verificao dinmica do comportamento de um programa em um conjunto finito de casos de teste contra o comportamento esperado.

Manuteno de software aborda defeitos e novos requisitos durante a operao do software.

Gerncia de Configurao de Software um processo que envolve a gesto de projetos, as atividades de desenvolvimento, manuteno e garantia.

A Gerncia de Engenharia de Software pode ser definida como a aplicao de atividades de gesto - planejamento, coordenao, medio, monitoramento, controle e divulgao para garantir que o desenvolvimento e a manuteno de software seja sistemtica, disciplinada e quantificada.

O processo de engenharia de software inclui atividades tcnicas e de gesto dentro dos processos do ciclo de vida de software. Alm disso, est preocupado com a definio, implementao, avaliao, gerenciamento da mudana e melhorias nos prprios processos do ciclo de vida de software.

Ferramentas de desenvolvimento de software so ferramentas baseadas em computador que apoiam os processos de ciclo de vida de software. Os mtodos impe uma estrutura na atividade de engenharia de software.


17

ULBR

A E

duca

o a

Dist

nci

aA rea de Qualidade de Software enfoca questes relacionadas qualidade do software, tanto do produto quanto do processo de desenvolvimento do software.

As disciplinas relacionadas com a Engenharia de Software, segundo o SWEBOK, incluem, so:

Engenharia da computao;

Cincia da computao;

Administrao;

Matemtica;

Gesto de projetos;

Gesto da qualidade;

Ergonomia de soft ware;

Engenharia de sistemas.

1.6 Pirmide da Engenharia de SoftwareA Engenharia de Software pode ser representada em forma de uma pirmide (figura 1.2), em que os conceitos mais importantes ficam em sua base e os mais volteis (e menos importantes) em seu topo.

Figura 1.2 Pirmide da Engenharia de Software

O conceito mais importante no estudo e prtica da Engenharia de Software seu foco na qualidade, ou seja, o atendimento e satisfao dos desejos e necessidades do usurio. Esta a razo de ser da Engenharia de Software.

A qualidade garantida pelo uso de processos de desenvolvimento de software corretos e robustos, com produtividade e eficincia. Estes processos podem ser ditos tradicionais como modernamente denominados de geis.

Os processos, por sua vez, so implementados atravs de mtodos, que descrevem como o software deve ser desenvolvido.


18

ULBR

A E

duca

o a

Dist

nci

a E, finalmente, as ferramentas so facilitadoras de todo esse processo. Nesta categoria entram as linguagens de programao, ferramentas de modelagem, ferramentas de teste, entre outras. So volteis, pois facilmente so superadas e substitudas por novas e que apresentam melhor desempenho.

1.7 Princpios da Engenharia de SoftwareA Engenharia de Software, com seu foco em qualidade, baseia-se em uma srie de princpios, que so declaraes gerais e abstratas, e que descrevem as propriedades desejadas dos processos de desenvolvimento e de seus produtos relacionados.

Os principais princpios abordam tpicos como:

Rigor e formalismo O processo de desenvolvimento de soft ware uma atividade baseada fortemente em criatividade e inspirao. O rigor e o formalismo devem coexistir como forma de complemento a esta criatividade. As prprias linguagens de programao j aplicam este princpio, visto que desvios e falhas de codifi cao no so toleradas pelos compiladores.

Separao de preocupaes Este princpio visa tratar individualmente de diferentes aspectos de um problema, de forma a concentrar esforos separadamente. Segundo ele, a nica forma de dominar a complexidade do projeto separar as preocupaes e decises do projeto. Primeiramente, algum deve tentar isolar problemas que esto menos relacionados com outros. Como exemplos desta separao, pode-se considerar regras de negcio e interface.

Modularizao O princpio da modularizao visa primordialmente dividir a complexidade. Soft wares que no so divididos de alguma forma so considerados monolticos, enquanto soft wares baseados em mdulos so chamados de modulares. O principal benefcio da modularizao que ela permite que o princpio da separao de preocupaes seja aplicado em duas fases. Primeiramente quando tratarmos dos detalhes de cada mdulo isoladamente (ignorando detalhes dos outros mdulos) e, posteriormente, quando tratarmos das caractersticas globais de todos os mdulos, incluindo seus relacionamentos, o que possibilita interlig-los para formar um sistema ntegro e coeso. Em soft ware modulares, busca-se bastante coeso (todas as informaes relacionadas ao mdulo devem estar contidas no mesmo) e pouca inter-relao (necessidade de ligao entre mdulos distintos).

Abstrao Processo pelo qual se identifi ca os aspectos importantes de um fenmeno, ignorando seus detalhes.

Antecipao de mudanas Princpio que prega a habilidade de evoluo do software, pela preparao prvia para mudanas. Atualmente, pela


19

ULBR

A E

duca

o a

Dist

nci

adisseminao dos processos geis de desenvolvimento de soft ware, este princpio bastante controverso.

Generalizao Princpio que orienta o foco do desenvolvimento no problema mais geral e abrangente do negcio do cliente, partindo posteriormente para os problemas mais especfi cos e detalhados.

Incrementabilidade - o princpio que busca a perfeio ou a obteno dos objetivos atravs de passos que evoluem (ou so incrementados) ao longo do tempo.

Estes princpios apresentados devem ser considerados como guias de boas prticas para os processos de desenvolvimento de software, independentemente se tradicionais ou geis.

1.8 Qualidades Desejveis em um SoftwareTanto os processos de desenvolvimento quanto os produtos de software, para terem sucesso e aceitao no mercado, devem apresentar qualidades bsicas, como:

Corretude O soft ware deve ser correto, isto , funcionar de acordo com sua especifi cao formal.

Confi abilidade Um soft ware considerado confi vel quando os seus usurios podem depender dele. Este conceito, porm, bastante relativo e depende dos tipos de usurios envolvidos. O prprio sucesso de mercado um indicador de confi abilidade: produtos no confi veis no sobrevivem por muito tempo.

Robustez Um soft ware, para ser robusto, deve apresentar capacidade de recuperar-se de erros e problemas no previstos, como quedas de energia, falhas de hardware etc. O nvel de robustez requerido depende do tipo de aplicao jogos e aplicaes simples podem ter robustez menor que aplicaes de misso criticam, como controles de usinas nucleares.

Performance A qualidade de performance diz respeito ao desempenho do soft ware em determinado hardware. Problemas de performance afetam principalmente sua usabilidade e, assim como a robustez, dependem do propsito da aplicao.

Amigabilidade Qualidade de um soft ware com facilidade de utilizao por parte de usurios. Esta qualidade relativa e depende do nvel e perfi l do usurio.

Manutenabilidade Qualidade de todos os soft wares com facilidade de alteraes aps sua liberao. Pode ser classificada como corretiva, que possibilita a correo de defeitos e problemas; perfectiva, que possibilita a


20

ULBR

A E

duca

o a

Dist

nci

a melhoria continua do produto ao longo do tempo de vida til; e adaptativa, que aborda a adaptao do soft ware a diferentes plataformas computacionais.

Reusabilidade Qualidade de processo de desenvolvimento que prega a reutilizao no somente de cdigo-fonte, mas de aspectos de projeto e teste.

Portabilidade Qualidade do soft ware com capacidade de execuo em diferentes plataformas computacionais. Esta qualidade atualmente importante devido ao grande nmero de plataformas computacionais a disposio do usurio computadores de mesa, notebooks, smarthphones e tablets, por exemplo.

Interoperabilidade Qualidade referente ao soft ware que permite interao com demais soft ware para fi ns de compartilhamento de dados e informaes. Um exemplo bastante conhecido de soft ware com interoperabilidade do Microsoft O ce, que permite a troca de dados entre seus aplicativos de edio de texto, planilha eletrnica e de apresentaes, sem necessidade de redundncia.

AtividadesComplete com V (verdadeiro) ou F (falso) para as seguintes afirmaes:

Engenharia de Software se caracteriza pelo estabelecimento de slidos princpios para se obter software confivel e que funcione.

O objetivo final da Engenharia de Software o lucro e a confiabilidade.

Definir a linguagem de desenvolvimento mais importante do que definir o processo de desenvolvimento.

Rigor e formalismo anulam o fato do desenvolvimento de software ser baseado em criatividade e inspirao.

O objetivo da modularizao produzir software com baixa coeso e muito inter-relacionamento.

Bibliografia ANDRADE, Vtor. Introduo ao Guia SWEBOK. Disponvel em http://www.cin.ufpe.br/~processos/TAES3/slides-2012.2/Introducao_SWEBOK.pdf.

GUSTAFSON, David. Engenharia de Soft ware. Porto Alegre: Bookman, 2003.

PRESSMAN, Roger. Engenharia de Soft ware, uma abordagem profi ssional. 7. Edio. Porto Alegre: McGraw-Hill/Bookman, 2011.

SCHACH, Stephen. Engenharia de Soft ware: Os Paradigmas Clssico e Orientado a Objetos. 7. Edio. So Paulo: McGraw-Hill, 2009.


21

ULBR

A E

duca

o a

Dist

nci

aSOMMERVILLE, Ian. Engenharia de Soft ware. 9. Edio. So Paulo: Pearson, 2011.

TONSIG, Srgio Luiz. Engenharia de Soft ware Anlise e Projeto de Sistemas. So Paulo: Futura, 2003.

Gabarito:

V V F F F


22

ULBR

A E

duca

o a

Dist

nci

a


2 PROCESSOS DE SOFTWARELus Fernando Fortes Garcia, prof. Dr.

Este captulo apresenta os Processos de Desenvolvimento de Software e os Modelos de Desenvolvimento de Software Tradicionais.

Estes modelos so importantes como guias de boas prticas em ambientes tradicionais de desenvolvimento de software. So discutidos aspectos positivos e negativos de cada modelo, bem como sua aplicabilidade.

2.1 Processos e Software Processo de software, segundo Sommerville (2011) um conjunto de atividades relacionadas que levam produo de software, e um conjunto de etapas ou nveis que formam o que se convencionou chamar de ciclo de vida de um software.

Independentemente do modelo de processo de software, se tradicional ou gil, pode-se destacar cinco atividades ou etapas fundamentais para o processo de desenvolvimento de software:

Especifi cao Requisitos e funcionalidades que devem ser implementadas no soft ware o que deve ser feito;

Projeto Etapa onde defi ne-se como o soft ware dever ser desenvolvido como o soft ware ser feito;

Implementao Etapa relacionada a codificao (programao) do soft ware;

Validao Etapa onde o soft ware deve ser validado (testado) frente aos requisitos;

Evoluo Etapa posterior entrega/homologao que visa manter/corrigir e evoluir o soft ware.


24

ULBR

A E

duca

o a

Dist

nci

a 2.2 Modelos de Processos de SoftwareUm modelo de processo de software uma representao abstrata do processo. Ele apresenta a descrio de um processo a partir de uma perspectiva particular, mostrando as atividades e sua sequncia (Sommerville, 2011). So usados para expressar abordagens de desenvolvimento de software e, geralmente, podem e devem ser adaptados e personalizados para atendimento de demandas especficas.

Os modelos podem, ento, ser classificados em Artesanais, Tradicionais ou geis.

Artesanais Modelos de desenvolvimento sem qualquer preocupao formal com a Engenharia de Soft ware. No h etapas, documentos ou papis (atores) formalmente defi nidos. popularmente conhecido como gambiarra.

Tradicionais Modelos clssicos, que foram criados a partir da dcada de 1970 e implantam a maioria dos conceitos e prticas da Engenharia de Soft ware;

geis Modelos modernos, criados a partir de dissidncias entre Engenheiros de Soft ware e grupos de desenvolvedores experientes, que questionam e se opem a vrios princpios da Engenharia de Soft ware. Sugerem novas prticas e abordagens para o desenvolvimento de soft ware.

Os modelos geis especialmente a Extreme Programming (XP) e o SCRUM sero detalhadamente abordados no prximo captulo deste material.

2.3 Modelo CascataO modelo Cascata (ou waterfall) o modelo de desenvolvimento de software mais antigo e mais clssico. Ainda bastante utilizado em empresas de desenvolvimento de software ao redor do mundo, entretanto, em verses adaptadas/atualizadas.

A verso original do modelo extremamente rgida e linear - no poderia ser utilizada atualmente frente ao novo contexto mundial, que apresenta mudanas frequentes de requisitos, equipes multidisciplinares com trabalho em paralelo, entre outras limitaes ao modelo original. O fato de exigir particionamento inflexvel do projetos em etapas estanques dificulta a resposta aos requisitos de mudana dos clientes.

O modelo cascata particularmente adequado a grandes projetos de software, como sistemas de ERP, e a equipes de desenvolvimento geograficamente distribudas, em que a diviso de etapas e a documentao so fatores positivos para a gerncia do projeto.


25

ULBR

A E

duca

o a

Dist

nci

aAs etapas do modelo cascata podem ser observadas na figura 2.1:

Figura 2.1 - Modelo Cascata. Fonte: (Sommerville, 2011)

Etapa de Engenharia de Requisitos Esta etapa inclui o processo de engenharia de requisitos (O QUE deve ser feito), com fases de elicitao (obteno atravs de entrevistas, questionrios, prottipos), especificao (usando tcnicas de modelagem como UML, atravs de diagramas de casos de uso, classes e sequncia) e validao e verificao (verificar se tanto os requisitos esto descritos e modelados tecnicamente corretos - em UML correta, por exemplo - quanto se representam os anseios corretos dos clientes/usurios).

Os profissionais responsveis por esta etapa incluem os Analistas, tanto Analistas de Negcios e quanto Analistas de Sistemas. Os Analistas de Negcios profissionais com perfil mais especializado em regras de negcios e gesto de pessoas normalmente ficam com as primeiras etapas, relacionadas abordagem e obteno dos requisitos, e os Analistas de Sistemas com as etapas seguintes, relacionadas ao registros/especificao e validao/verificao dos requisitos.

Um subprocesso da Engenharia de Requisitos pode ser observado na figura 2.2:


26

ULBR

A E

duca

o a

Dist

nci

a 2.2 Engenharia de Requisitos. Fonte: (SOMMERVILLE, 2011)

Destaca-se a subetapa de Estudo de Viabilidade, onde so realizados estudos de viabilidade tcnica e econmica acerca do possvel desenvolvimento do software.

Os fatores que devem ser levados em considerao nesta subetapa incluem viabilidade comercial/econmica (o mercado para sua comercializao) e tcnica (os conhecimentos tcnicos requeridos para seu desenvolvimento, em plataforma computacional - desktop, mvel, distribuda -, linguagens de programao, sistemas de banco de dados e testes).

Neste ponto, costuma-se dividir o software em dois tipos: Software de Prateleira e Software sob Encomenda. Software de Prateleira aquele desenvolvido pela empresa ainda sem nenhum cliente especfico, para posterior venda em empresas especializadas, em lojas e sites de comrcio eletrnico. Software sob Encomenda, por sua vez, aquele desenvolvido pela empresa sob encomenda particular e direta de determinado cliente.

Ao contrrio que se pode pensar, mesmo Softwares sob Encomenda devem passar por esta subetapa, visto que mesmo tendo garantia a comercializao podem apresentar problemas tcnicos e/ou de projetos, relacionados a prazos e custos. Insistir no desenvolvimento de um software com viabilidade incerta ter problemas no futuros, como perdas de mercado, perdas financeiras e atrasos, bem como problemas relacionados imagem da empresa e dos profissionais envolvidos.

Projeto Esta etapa inclui atividades relacionadas definio da melhor soluo tcnica a ser aplicada no desenvolvimento do software. Aqui define-se COMO o software ser feito sem, necessariamente, faz-lo/implement-lo.


27

ULBR

A E

duca

o a

Dist

nci

aO profissional responsvel por esta etapa conhecido por arquiteto de software, que tradicionalmente foi, antes, um programador experiente, com boa viso tanto tcnica quanto relacionada gerncia de projetos prazos, riscos e custos.

Um subprocesso desta etapa pode ser observado na figura 2.3:

2.3 Projeto de Software. Fonte: (SOMMERVILLE, 2011)

A partir da especificao dos requisitos (produto da fase anterior do modelo cascata) o arquiteto inicia a definio da soluo tcnica, incluindo a arquitetura do sistema (diviso do sistema em mdulos e suas interfaces (ligaes), especificao de partes de cdigo, chegando definio de estruturas de dados (como matrizes e listas encadeadas) e, ainda, se necessrio, exemplos de algoritmos que possam guiar o programador na maneira mais adequada na implementao do software. Nesta fase, na prtica, so definidos tanto o ambiente de desenvolvimento, as linguagens de programao, os bancos de dados e os frameworks a ser utilizados.

considerada fase vital para o sucesso do desenvolvimento do software, visto que uma implementao incorreta (ou no adequada) pode levar a baixo desempenho (principalmente relacionado a integrao com bases de dados), duplicidade desnecessrias de dados, entre outros problemas.

Implementao Nesta fase, ocorre a codificao/programao dos requisitos de software, baseado nas definies tcnicas da fase de projeto. A implementao atualmente utiliza linguagens de programao visuais e orientadas a objeto, com ambientes de desenvolvimento fceis e amigveis.

O profissional responsvel por esta etapa conhecido por Programador ou Desenvolvedor, cujo perfil apresenta excelentes capacidades lgicas e analticas.


28

ULBR

A E

duca

o a

Dist

nci

a Teste de Software Esta etapa visa aplicar testes de software que buscam descobrir erros e falhas que porventura tenham ficado desde as etapas anteriores. O processo de teste nunca 100% efetivo, e muitos erros certamente ainda restaro para serem descobertos em ambiente de produo, ou seja, pelos prprios clientes e usurios.

O profissional desta etapa do modelo de desenvolvimento conhecido genericamente como Testador, com variaes entre Gerente de Testes, Projetista de Testes, Testador, Automatizador de Testes, entre outros.

O subprocesso (figura 2.4) de teste envolve deste o teste unitrio e especfico de cada componente/mdulo do software (teste de componente), passando por um teste de integrao destes componentes/mdulos (teste de sistema) e chegando ao teste de aceitao por parte do cliente/usurio, tambm conhecido por teste de homologao.

2.4 Teste de Software. Fonte: (SOMMERVILLE, 2011)

Evoluo Esta fase inicia aps a entrega do produto de software e inclui atividades de manuteno e evoluo do software (figura 2.5).

2.5 Evoluo de Software. Fonte: (SOMMERVILLE, 2011)

2.4 Modelo Evolutivo ou EvolucionrioO Modelo Evolutivo baseia-se no levantamento rpido de requisitos, projeto rpido e na construo evolutiva de prottipos de software, que sero avaliados e refinados at a liberao do mesmo. O Modelo Evolutivo pode ser observado na figura a seguir:


29

ULBR

A E

duca

o a

Dist

nci

a2.6 Modelo Evolutivo. Fonte: (SOMMERVILLE, 2011)

Seu objetivo principal a solidificao (certeza) nos requisitos juntos aos clientes/usurios, sendo a direo do desenvolvimento determinada pela experincia operacional.

A aplicabilidade do Modelo Evolutivo d-se em sistemas interativos de pequeno e mdio portes e sistemas com ciclo de vida curto, para aplicaes especficas e datadas. Um software de gerncia de um sorteio de uma emissora de rdio pode ser considerado um exemplo de aplicabilidade do modelo, visto que simples, agrega funcionalidades aos poucos (cadastros de participantes, cadastros de brindes e, finalmente, mecanismos de sorteio). Alm da simplicidade, este software ter uma vida til bastante curta, em paralelo com o perodo de vigncia da promoo.

Como problemas, pode-se citar a falta de visibilidade geral do processo, a m estruturao tcnica do sistema (pelos projetos rpidos e sem cuidados) e a necessidade de profissionais especializados em linguagens de prototipao rpida. Outro problema a ser destacado a necessidade constante de iterao por parte do cliente/usurio final nas etapas de validao das verses intermedirias, que pode levar a um grande descontentamento e stress em ambas as partes.

2.5 Modelo Iterativo IncrementalO modelo Iterativo-Incremental baseia-se na premissa da constante evoluo e alterao dos requisitos, de modo que no seria interessante tanto aguardar por uma improvvel estabilizao quanto desenvolver completamente o sistema para depois adequ-lo na manuteno.

O processo do modelo Iterativo-Incremental (figura 2.7) parte de um conjunto de requisitos iniciais e estveis, e com base nestes, projeta a arquitetura completa do


30

ULBR

A E

duca

o a

Dist

nci

a sistema (principal diferena em relao ao modelo Evolutivo visto anteriormente). Com base na arquitetura e na agregao dos demais requisitos, o sistema vai sendo construdo, passo a passo, com atividades tradicionais de anlise-projeto-codificao e testes.

2.7 - Modelo Iterativo-Incremental. Fonte: (Sommerville, 2011)

Como possvel principal problema deste modelo destaca-se a dependncia extrema da definio dos requisitos por parte dos clientes, o que pode afetar criticamente o projeto em relao a prazos e principalmente seus custos.

2.6 Modelo Baseado em ComponentesO Modelo Baseado em Componentes prev o desenvolvimento do software atravs da integrao de componentes pr-prontos disponveis no mercado. Atualmente, existem vrias empresas no mercado atuando exclusivamente na fabricao de componentes genricos a serem utilizados em projetos especficos de desenvolvimento de aplicaes de software.

O processo deste modelo inicia com a tradicional especificao de requisitos, mas, posteriormente, ao invs de fases como projeto e codificao, parte para uma pesquisa e anlise de componentes disponveis e, caso seja necessrio, para sua modificao antes da integrao no produto de software final (Figura 2.8).

2.8 - Modelo Baseado em Componentes. Fonte: (Sommerville, 2011)


31

ULBR

A E

duca

o a

Dist

nci

aCertamente nem todos os requisitos particulares podem ser implementados somente com componentes pr-prontos, levando a uma necessidade de desenvolvimento prpria dos restantes.

Como principal problema do Modelo Baseado em Componentes destaca-se a necessidade de confiana na qualidade do componente adquirido junto a terceiros, bem como a possvel necessidade de modificao em softwares que podem no apresentar documentao adequada.

A aplicabilidade deste modelo d-se em aplicaes de software tradicionais/clssicos, ou seja, com poucos requisitos especficos, como softwares de cadastros e emisso de relatrios.

2.7 Modelo RUP Rational Unified Process O modelo RUP (Rational Unified Process) um modelo de desenvolvimento de software derivado da UML e do respectivo processo unificado de desenvolvimento de software, que separa um conjunto de atividades a partir de um conjunto pr-definido e bem conhecido de fases. Aborda trs perspectivas: Fases do projeto; Atividades do projeto; Boas prticas de desenvolvimento.

2.9 - Modelo RUP.


32

ULBR

A E

duca

o a

Dist

nci

a As fases do modelo RUP (figura XX) incluem: Iniciao - defi ne o escopo do projeto; Elaborao defi ne os requisitos e a arquitetura do sistema; Construo desenvolvimento do soft ware; Transio implantao do soft ware.

As boas prticas do RUP versam sobre: Desenvolvimento iterativo do soft ware; Gerncia de requisitos; Utilizao de arquiteturas baseadas em componentizao; Modelagem visual Verifi cao da qualidade do soft ware; Foco em Controle de mudanas do soft ware.

AtividadesComplete com V (verdadeiro) ou F (falso) para as seguintes afirmaes:

O modelo cascata, em sua verso original, pode ser usado por equipes globais que trabalhem em paralelo ...

Softwares desenvolvidos sob encomenda no precisam passar pela subetapa de estudo de viabilidade, pois j tem cliente garantido ...

O subprocesso de projeto de arquitetura considerado muito importante pois pode evitar problemas de integrao com bases de dados ...

O modelo evolutivo se aplica quando os projetos so longos e tero ciclo de vida completo ...

O modelo incremental apresenta forte dependncia do relacionamento com o cliente ...

O modelo baseado em componentes favorece a reusabilidade do software ...

BibliografiaGUSTAFSON, David. Engenharia de Soft ware. Porto Alegre: Bookman, 2003.

PRESSMAN, Roger. Engenharia de Soft ware, uma abordagem profi ssional. 7. Edio. Porto Alegre: McGraw-Hill/Bookman, 2011.


SOMMERVILLE, Ian. Engenharia de Soft ware. 9. Edio. So Paulo: Pearson, 2011.


Gabarito: F V V F V


3 PROCESSO GEIS DE SOFTWARELus Fernando Fortes Garcia, prof. Dr.

Este captulo apresenta os Processos geis de desenvolvimento de software, discutindo os conceitos de agilidade, GAP (Gerenciamento gil de Projetos), XP (Extreme Programming) e SCRUM.

Os processos geis tornaram-se excelentes alternativas aos processos tradicionais de desenvolvimento de software, visto que implementam/abordam de forma atual/moderna vrias questes fundamentais do processo de software, como o gerenciamento de requisitos mutveis.

3.1 Processos geis de Software O principal conceito envolvido neste captulo o conceito de Agilidade:

Agilidade a habilidade de criar e responder a mudanas como forma de manter a lucratividade num ambiente turbulento de negcios Highsmith, 2002;

Os chamados mtodos geis surgem em paralelo fevereiro de 2001 - a um novo contexto da indstria de desenvolvimento de software, onde, nestes novos tempos, temos uma grande demanda de software e, adicionalmente, de um software cada vez mais complexo sistemas inteligentes, distribudos, computao em nuvem etc. Alm disso, junta-se a este panorama o aumento da questo dos requisitos mutantes, devido a mudanas de mercado, de governo (leis, taxas, impostos etc.).

Entretanto, apesar do movimento ter sido formalizado em 2001, os principais conceitos envolvidos so mais antigos, como citados em (RICO, 2005):

Times auto-organizveis em pesquisa desde 1951, com Bachuk e Goode;

Prototipao (em Engenharia de Soft ware) 1982, com McCracken e Jackson;


34

ULBR

A E

duca

o a

Dist

nci

a Releases e iteraes desde 1975, com pesquisas de Basili e Turner;

Envolvimento do cliente desde 1978, em artigos de Von Hippel.

Os Mtodos geis so uma tentativa patrocinada originalmente por um grupo de desenvolvedores/programadores experientes e consultores (Kent Beck, notadamente) que questionam e se opem s prticas de at ento da Engenharia de Software de abordagem e minimizao de uma srie de problemas da rea de desenvolvimento de software clssica/tradicional:

Suposio de que seja possvel prever o futuro;

Baixa interao com clientes;

nfase em documentos e processos.

Uma famosa pesquisa, o Chaos Report, do instituto de pesquisas Standish Group, monitora h dcadas o mercado de projetos de desenvolvimento de software, classificando-os em sucesso, problema e fracasso.

Figura 3.1 Chaos Report. Fonte. Standish Group.

Outro fator analisado pelo Standish Group, dentro do contexto do desenvolvimento de software envolve a questo do percentual das funes utilizadas em um sistema tpico de software. A pesquisa descobriu que:

Partes sempre usadas: 07%

Partes raramente usadas: 19%

Partes nunca usadas: 45%

Partes utilizadas as vezes: 29%

Como se pode ver, gasta-se muito tempo e dinheiro desenvolvendo softwares que provavelmente nunca sero usados.


35

ULBR

A E

duca

o a

Dist

nci

aO movimento, ento, surge com a publicao de um manifesto com quatro questes principais (www.agilemanifesto.org/):

1. Indivduos e interaes mais do que processos e ferramentas;

2. Soft ware em funcionamento mais do que documentao abrangente;

3. Colaborao com o cliente mais do que negociao de contratos;

4. Responder a mudanas mais do que seguir um plano.

O principal objetivo deste manifesto Satisfazer o cliente, entregando, rapidamente e com frequncia, sistemas com algum valor, ou seja, com entregas funcionais e frequentes, com preparao e tratamento de requisitos mutveis, com pessoal de desenvolvimento e negcios trabalhando juntos e com troca direta de informaes, sem burocracias.

Os princpios dos Mtodos geis incluem:

Satisfao do cliente atravs de entrega contnua e adiantada de soft ware com valor agregado;

Mudanas nos requisitos so bem vindas, mesmo tardiamente;

Entregar frequentemente soft ware funcionando;

Pessoal de desenvolvimento e negcios trabalhando junto;

Indivduos motivados;

Conversas presenciais;

Andamento do progresso medido pelo funcionamento do soft ware;

Desenvolvimento sustentvel;

Busca da excelncia tcnica e do bom design;

Simplicidade;

Equipes auto-organizveis;

Refl exes peridicas.

A grande abordagem dos Mtodos geis surge da manipulao correta das conhecidas variveis de um projeto de software em busca do sucesso e da qualidade. Enquanto os processos Tradicionais manipulam (tanto positivamente quanto negativamente) a qualidade, mantendo fixos o tempo, escopo e custo, os projetos geis focam-se no escopo, mantendo fixos, por sua vez, tempo, qualidade e custo.


36

ULBR

A E

duca

o a

Dist

nci

a Uma possvel comparao entre os modelos Tradicionais e geis de desenvolvimento de software pode ser observada na tabela 3.1:

Tabela 3.1 Comparao entre Enfoques.

Item Enfoque Clssico Enfoque gil

Gerenciamento Controle absoluto Colaborao e Liderana

Papis/atores Individual Equipes (auto-organizadas)

Cliente Importante (no incio) Crtico (sempre)

Desenvolvimento Tradicional (cascata e outros) gil (XP e outros).

Esta comparao, mais especificamente relacionada visibilidade, adaptabilidade, valor de negcio e ao risco pode ser analisada nos grficos abaixo, onde o eixo vertical representa o item analisado e o eixo horizonte representa o tempo (Figura 3.2):

Figura 3.2 Comparao gil x Tradicional. Fonte: www.versionone.com

As principais metodologias geis incluem:

FDD Feature Driven Development;

Extreme Programming;

Lean Development;

Crystal;

Scrum;


37

ULBR

A E

duca

o a

Dist

nci

aAs caractersticas comuns a todos os mtodos geis citados acima incluem focar nas pessoas (desenvolvedores e clientes) e no focar em processos e documentaes rgidas e detalhadas.

Visam, ao final, mesmo contrapondo vrias premissas da Engenharia de Software, ser considerados como um conjunto coeso e consistente de Boas Prticas para projetos de desenvolvimento de software.

3.2 XP Extreme ProgrammingA Extreme Programming a principal metodologia de desenvolvimento gil, criada por Kent Beck, Ron Jeffries e Ward Cunningham.

Surge como uma alternativa aos modelos tradicionais de desenvolvimento de software, representados principalmente pelo Modelo Cascata. focada primordialmente na figura do programador, sem contudo apresentar nveis hierrquicos no processo de desenvolvimento. Normalmente indicada para programadores experientes, que com XP ganham liberdade para codificar.

As premissas ou princpios do modelo XP baseiam-se numa mudana de proposta de atitude dos desenvolvedores, no sentido de: Tomar decises importantes o mais tarde possvel ; Implementar somente o necessrio neste momento; No implementar cdigo desnecessrio (ao contrrio do princpio de

Antecipao de Mudanas da Engenharia de Soft ware); Feedback rpido e constante; Simplicidade; Alta qualidade de cdigo-fonte;

Destes, pode-se apontar valores a serem destacados: Respeito; Comunicao; Coragem; Simplicidade; Feedback.

A XP destina-se, ainda, a um cenrio bem definido dentro do mbito global de desenvolvimento de software, em: Grupos pequenos de 2 a 10 desenvolvedores; Projetos pequenos de 1 a 12 meses previstos; Soft wares pequenos at 250.000 linhas de cdigo.


38

ULBR

A E

duca

o a

Dist

nci

a Os papis profissionais em uma equipe XP incluem:

Programadores;

Coach (treinadores ou tcnicos) normalmente o programador mais experiente do grupo, responsvel pelo controle da equipe nos instantes iniciais do projeto;

Tracker (acompanhador) programador responsvel pela gerncia do projeto, em relao s estimativas e cobrana de tempos e custos;

Cliente - a participao do cliente real ou representado por um desenvolvedor fator chave no sucesso de um projeto de desenvolvimento XP. Ao cliente cabe a tarefa de escrever histrias (requisitos).

O XP representado por um conjunto de 12 prticas originais/oficiais. O atendimento das prticas garante o ambiente necessrio ao desenvolvimento XP.

Planejamento

Fases pequenas

Metforas

Design simples

Testes

Refatorao

Programao pareada

Propriedade coletiva do cdigo

Integrao contnua no projeto

Semana de trabalho de 40horas

Permanncia do cliente junto ao time de desenvolvimento

Padronizao do cdigo

O processo de um projeto XP tipicamente apresenta as seguintes etapas:

Seleo de histrias (story cards) contendo os requisitos do cliente;

Seleo de um par livre para programao pareada Atividade no aleatria, visto que o objetivo da programao pareada o desenvolvimento das habilidades de todos os elementos da equipe;

Seleo, dentro da histria, de um carto contendo uma necessidade especfi ca;

Discusso, em par, das alteraes recentes no soft ware;


39

ULBR

A E

duca

o a

Dist

nci

a Testes o teste considerado um dos principais seno o principal pilar de sucesso e segurana no modelo XP. Os desenvolvedores costumam executar testes antes, durante e depois da codifi cao, visando garantir que o cdigo adicionado ao projeto est correto e funciona adequadamente; Engloba tanto testes unitrios quanto testes funcionais;

Codifi cao No XP, na programao pareada, somente um desenvolvedor programa/codifi ca. O outro desenvolvedor deve fi car ao lado, analisando o cdigo e propondo contraexemplos e planos de testes; Este cdigo sempre poder ser refatorado, ou seja, melhorado em busca de excelncia tcnica e adequao a um padro ofi cial de codifi cao da equipe. Visto tambm que a documentao em um projeto XP bastante reduzida, na etapa de codifi cao enfatizada a necessidade de incluso de comentrios padronizados junto s linhas de cdigo;

Integrao Integrao final do cdigo ao repositrio do projeto do soft ware.

XP normalmente funciona muito bem, desde que respeitadas suas caractersticas bsicas (equipes pequenas e experientes, projetos curtos e dinmicos, entre outras). Entretanto, quando o cenrio do desenvolvimento no adequado (cliente no est disposto a participar/colaborar, projetos grandes - e estveis -, necessria uma especificao completa do software antes do processo iniciar, os programadores no so suficientemente experientes e capazes de autogerenciamento) XP no deve ser imposta fora, j que certamente ir gerar mais problemas do que solues.

3.3 SCRUMSCRUM o principal framework do Gerenciamento gil de projetos (GAP) que, segundo Highsmith (Highsmith, 2004) um conjunto de valores, princpios e prticas que auxiliam equipes de projetos a entregar produtos ou servios de valor em um ambiente complexo, instvel e desafiador.

Os principais objetivos do GAP incluem:

Inovao contnua;

Adaptabilidade de pessoas, produtos e processos;

Reduo dos tempos de entrega planejamento de curto prazo;

Resultados confi veis anlise do progresso real do projeto;

Simplicidade;

Foco na soluo, ao invs de foco nos problemas;

Remoo de barreiras ao orgulho da execuo;


40

ULBR

A E

duca

o a

Dist

nci

a Engajamento e poder s pessoas;

Para tanto, so sugeridas boas prticas no Gerenciamento gil de Projetos, especifi camente em projetos de desenvolvimento de soft ware:

Foco e envolvimento de pessoas clientes e desenvolvedores;

Foco em iteraes entregas parciais;

Plano de projeto de alto nvel e alta qualidade;

Segundo Chin (2004), a aplicabilidade ideal de GAP em projetos de desenvolvimento de software d-se em:

Projetos de desenvolvimento de novos produtos nico cliente;

Projetos de desenvolvimento de novas plataformas/tecnologias nico cliente.

GAP, ainda segundo Chin, no adequado para desenvolvimento de projetos meramente operacionais, independente do tipo de cliente (nico ou em forma de conglomerado). Entretanto, este conceito mais recentemente est sendo bastante questionado, principalmente pela comunidade de desenvolvimento de projetos de software geis.

SCRUM foi criado por Jeff Sutherland e Ken Schwaber, baseados no artigo The new product development Game, de Hirotaka Takeuchi e Ikujiro Nonaka, de 1986.

SCRUM pode ser definido como um framework para tratamento e resoluo de problemas complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possvel, sendo ento leve e simples de entender, porm, difcil de dominar. importante frisar que SCRUM no apenas um processo nem uma tcnica, mas sim um framework dentro do qual so possveis empregar vrios processos e diversas tcnicas.

Scrum , ento, um processo iterativo e incremental para desenvolvimento de projetos com foco em comunicao e trabalho em equipes, preocupado, primordialmente, com os fatores tempo e valor de negcio. O tempo (time boxes) destacado no SCRUM por ser limitado e aplicado a tudo, incluindo deste reunies a sprints.

O cenrio ideal de aplicao do framework SCRUM so projetos com aspectos de tecnologia (plataformas) complexos, com requisitos adaptveis e dinmicos (igualmente complexos).

O processo do SCRUM d-se atravs da figura 3.3.


41

ULBR

A E

duca

o a

Dist

nci

aFigura 3.3 SCRUM. Fonte: http://epf.eclipse.org/wikis/scrumpt/Scrum/guidances/sup-portingmaterials/resources/ScrumLargeLabelled.png

Os eventos ou cerimnias do SCRUM incluem tradicionalmente: Reunio de planejamento de release (requisitos completos) mais de 8 horas

de durao;

Reunio de planejamento da Sprint (requisitos selecionados) 8 horas de durao;

Sprint de 2 a 4 semanas de durao;

Reunio diria de acompanhamento 15 minutos de durao, em p, com as questes:

O que eu fi z ontem;

O que vou fazer hoje;

Encontrei algum problema/impedimento?

Reunio de reviso da Sprint 4 horas de durao;

Reunio de retrospectiva da Sprint 4 horas de durao.

Os papis do SCRUM incluem:

PO (Product Owner) Responsvel pelos requisitos/conhecimento do negcio;

SCRUM Master Responsvel pelo processo SCRUM;

Time SCRUM Implementadores do SCRUM.

Os artefatos (documentos, relatrios e grficos) do SCRUM so normalmente representados por:

Product Backlog Lista geral/completa de requisitos priorizados pelo PO;

Spint Backlog Subconjunto de requisitos selecionados pelo Time Scrum;

Grfi co de Burndown Grfi co de acompanhamento do SCRUM.


42

ULBR

A E

duca

o a

Dist

nci

a AtividadesComplete com V (verdadeiro) ou F (falso) para as seguintes afirmaes:

Em se tratando de desenvolvimento gil, o teste de software no apresenta importncia, uma vez que realizado em paralelo ao desenvolvimento.

Mtodos geis so fortemente dependentes de interao com o cliente.

Os princpios nos quais se baseiam os mtodos geis so facilmente aplicveis a equipes globais.

O conceito de agilidade est fortemente associado a manter a lucratividade frente a turbulncia dos mercados.

No SCRUM, o PO (product owner) no apresenta relevncia considervel no time de desenvolvimento.

BibliografiaCHIN, G. Agile Project Management: how to succeed in the face of changing project requirements. 2004. NY: Amacon.

GUSTAFSON, David. Engenharia de Soft ware. 2003. Porto Alegre. Editora Bookman.

HIGHSMITH, J., Agile Project Management, Creating innovative products. 2004. AddisonWesley.

PRESSMAN, Roger. Engenharia de Soft ware, uma abordagem profi ssional. 7. Edio. 2011. Porto Alegre. Editora McGraw-Hill/Bookman.

RICO, David. Agile Methods for Developing Internet Products, Customer Satisfaction, and Firm Performance. 2005. Disponvel em htt p://davidfrico.com/rico05b.pdf,

SBROCCO, Jos. Metodologias geis Engenharia de Soft ware sob medida. 1. Edio. So Paulo: rica, 2012.


SHORE, James. WARDEN, Shane. A Arte do Desenvolvimento gil. Rio de Janeiro: Alta Books, 2008.

SOMMERVILLE, Ian. Engenharia de Soft ware. 9. Edio. So Paulo: Pearson, 2011.


Gabarito:

F V F V F


4 ENGENHARIA DE REQUISITOSLus Fernando Fortes Garcia, prof. Dr.

Este captulo apresenta a Engenharia de Requisitos, a etapa que pode ser considerada como a mais importante em todo processo de desenvolvimento de software.

Nesta etapa definido o que o software deve fazer e, caso isto seja definido errado ou incompleto, estes erros sero replicados nas etapas subsequentes.

4.1 Engenharia de Requisitos Requisitos estabelecem o que o software deve fazer, servios que o software deve fornecer e definem as restries sobre suas operaes e implementao (SOMMERVILLE, 2011).

A etapa de Engenharia de Requisitos, de qualquer modelo de desenvolvimento de software, tradicional ou gil, certamente pode ser considerada a mais importante de todas (entre requisitos, projeto, codificao, teste, implantao, manuteno), visto que todo processo inicia por aqui e, sendo assim, quaisquer erros nesta fase so replicados nas demais, alguns inclusive impossibilitando sua deteco e correo.

Outro complicador na Engenharia de Requisitos vem do fato desta etapa ser a etapa com maior interao entre pessoas, isto , interao entre Analistas (de Negcio e Sistemas), Desenvolvedores e Clientes/Usurios. Infelizmente esta relao e/ou gesto de pessoas (abordagem, comunicao, confiana etc.) no faz parte do perfil da maioria dos profissionais de desenvolvimento de software, o que induz a erros, inconsistncias, falhas e lacunas em todo processo.


44

ULBR

A E

duca

o a

Dist

nci

a O cenrio atual de desenvolvimento de software, exibido na figura 4.1, mostra claramente que a rea de Requisitos merece ainda pouco mais de 5% dos investimentos em desenvolvimento de software, mesmo que sabidamente seja crtica e responsvel por mais da metade (55%) dos erros do software. Estes erros, quando descobertos e tratados no incio, ainda na fase de requisitos, tm um custo relativo de correo bastante baixo (fator 1). Entretanto, quando no descobertos a tempo, na fase de requisitos, so replicados nas etapas de projeto e codificao e seu custo e esforo de correo passa a ser multiplicado at por 100 vezes (fator 10 a 100) o custo inicial.

Figura 4.1 Custos de manuteno Fonte: (vila e Spinola, 2007)

% do custo de desenvolvimento

% dos erros introduzidos

% dos erros encontrados

Custo relativo de correo

Anlise de requisitos 5 55 1

Projeto 25 30 1 - 1.5

Codificao e teste de unidade 50

Teste 10 10 1 - 5

Validao e documentao 10

Manuteno 5 22 10 - 100

Na figura 4.2, tambm disponibilizada no artigo de vila e Spinola (2007), tem-se os fatores crticos de sucesso no processo de desenvolvimento de software. Esta tabela confirma que, de oito fatores crticos, ao menos metade (fatores 1, 2, 4 e 6) so diretamente relacionados a Requisitos de Software.

Figura 4.2 Fatores Crticos. Fonte: (vila e Spinola, 2007)

Fatores crticos %

1. Requisitos incompletos 13.1%

2. Falta de envolvimento do usurio 12.4%

3. Falta de recursos 10,6%

4. Expectativas irreais 9,9%

5. Falta de apoio executivo 9,3%

6. Mudana de requisitos e especificaes 8,7%

7. Falta de planejamento 8,1%

8. Sistema no mais necessrio 7,5%


45

ULBR

A E

duca

o a

Dist

nci

aRequisitos so importantes no processo de desenvolvimento de software para:

Estabelecer base de concordncia entre desenvolvedor/cliente;

Estabelecer uma referencia para a validao do produto fi nal;

Diminuir retrabalho no processo de desenvolvimento.

4.2 Definies de RequisitoRequisitos podem ser definidos, em forma crescente de complexidade e abrangncia, como em vila e Spinola (2007):

Descries das funes e restries do soft ware;

Propriedade que o soft ware deve exibir para resolver algum problema do mundo real;

Condio ou capacidade que deva ser alcanada ou estar presente em um sistema para satisfazer um contrato, padro, especifi cao ou outro documento formalmente imposto.

4.3 Tipos de RequisitosRequisitos tradicionalmente so classificados, primariamente, como:

Requisitos de Usurio Documentos e diagramas para clientes, contendo, em linguagem acessvel (s vezes mesmo linguagem natural), as principais funes e servios a serem disponibilizados no soft ware;

Requisitos de Sistema Documentos e diagramas mais estruturados, com detalhes tcnicos e operacionais do sistema, para todos os envolvidos no processo de desenvolvimento do software, desde analistas, arquitetos, programados e testadores. Escritos em linguagem tcnica de alto nvel, normalmente utilizando UML.

Outra classificao possvel dos requisitos aborda:

Requisitos Funcionais;

Requisitos No Funcionais;

Requisitos de Domnio.

Os Requisitos Funcionais descrevem as funcionalidades e funes do software, como o sistema deve reagir a entradas de dados, bem como o seu comportamento esperado.


46

ULBR

A E

duca

o a

Dist

nci

a Exemplos de Requisitos Funcionais:

O soft ware deve gerar relatrio de todos os clientes cadastrados;

O mdulo de contas a receber deve listar todos os clientes com contas vencidas a mais de 30 dias;

O cliente deve ser identifi cado no sistema pelo seu nmero de CPF.

Os Requisitos No Funcionais expressam condies e restries que devem ser atendidas pelo software, como restries de tempo, padres de desenvolvimento e de utilizao, padres de usabilidades, entre outros. Podem ser divididos entre vrios subtipos, como:

Requisitos de produto;

Requisitos de efi cincia;

{ Requisitos de desempenho;

{ Requisitos de espao;

Requisitos de confi abilidade;

Requisitos de portabilidade;

Requisitos organizacionais;

Requisitos de entrega;

Requisitos de implementao;

Requisitos de padres;

Requisitos externos;

Requisitos de interoperabilidade;

Requisitos ticos;

Requisitos legais;

{ Requisitos de privacidade;

{ Requisitos de segurana.

Como exemplos de Requisitos No Funcionais, pode-se citar:

O soft ware deve ser compatvel com os navegadores web Internet Explorer e Firefox;

O soft ware deve exibir o resultado das consultas em at 3 segundos em operaes que envolvam banco de dados;


47

ULBR

A E

duca

o a

Dist

nci

a Os dados dos clientes devem ser mantidos criptografados dentro do banco de dados.

Os Requisitos de Domnio so herdados do domnio da aplicao (financeiro, educacional, industrial, hospitalar etc.) e refletem diretamente as suas caractersticas. So considerados superiores aos Requisitos Funcionais e geralmente descrevem caractersticas gerais a toda aplicao. Como exemplos destes requisitos, tem-se:

O desconto mximo em operaes de venda no sistema ser de 10%;

O clculo da mdia fi nal nas disciplinas presenciais dar-se- pela mdia aritmtica entre todas as notas.

4.4 Processo da Engenharia de RequisitosA Engenharia de Requisitos aborda etapas e atividades relacionadas a toda vida til dos requisitos no software, desde sua obteno at sua manuteno e atualizao aps o desenvolvimento do software.

Pode ser dividido em dois grandes processos: Produo e Gerncia de Requisitos, onde ambos apresentam atividades essenciais para o sucesso do software.

O processo de Produo de Requisitos envolve atividades de:

Levantamento/Elicitao/Obteno;

Anlise e negociao;

Registro/Documentao;

Validao;

Verifi cao.

A etapa de Levantamento/Elicitao/Obteno responsvel pela obteno dos requisitos do software junto ao stakeholders (clientes e usurios diretamente envolvidos com o software). Para tanto, so desenvolvidas tcnicas e utilizadas ferramentas como:

Entrevistas conversas pessoais ou mediadas por computador entre analistas e stakeholders;

Questionrios documentos enviados por email previamente com questes envolvendo o que deve ser feito, como e por que?;

Prototipao construo conjunta de softwares provisrios junto aos stakeholders;

Como abordado anteriormente esta etapa, dentre todas do processo de Engenharia de Requisitos, certamente a mais complicada e arriscada dada a exigncia de


48

ULBR

A E

duca

o a

Dist

nci

a comunicao e interao entre pessoas. Normalmente existem problemas clssicos a serem abordados nesta fase, como:

Stakeholders no sabem o que querem ou como deve funcionar;

Desenvolvedores com baixo conhecimento do domnio de negcios do soft ware;

Problemas de comunicao entre as partes envolvidas confl itos, ambiguidades e obviedades no formalmente defi nidas;

A etapa de Anlise e Negociao crucial no processo de Produo de Requisitos, visto que responsvel, em um primeiro momento, pela anlise de viabilidade tcnica e comercial em relao ao desenvolvimento dos requisitos ( possvel desenvolver com as tcnicas, ferramentas e conhecimentos atuais? Tem sentido para o conjunto do sistema ser desenvolvido? O requisito no duplicado ou contraditrio com algum outro requisito?) e, posteriormente, caso seja necessrio, novos contatos com os stakeholders para negociao/readequao de ajustes nos requisitos anteriormente levantadas. Os mesmos problemas da etapa anterior so enfrentados aqui, multiplicados pela necessidade de negociao, que pode levar a desgostos e insatisfaes por partes dos envolvidos.

A etapa de Registro/Documentao responsvel pelo registro formal dos requisitos em documentos oficiais de requisitos da empresa. Este registro necessrio para posterior consulta, controle e evoluo dos requisitos. Estes documentos podem ser tanto utilizando linguagem natural (o que desaconselhvel, j que textos so propcios a problemas de interpretao) ou usando linguagens de modelagem como a UML (Unified Modeling Language), com seus diagramas de:

Casos de uso;

Classe;

Sequncia;

Atividades.

A etapa de Verificao responsvel pela anlise da documentao dos requisitos (produzida na etapa anterior) em busca de erros, falhas, ambiguidades, omisses e inconsistncias internas do processo de obteno e registro. Erros de modelagem UML, por exemplo, devem ser corrigidos nesta etapa.

J na etapa de Validao, busca-se o ciente e aprovado dos Stakeholders em relao aos requisitos. Esta assinatura de aprovao no deve ser considerada como definitiva visto que, como j foi comentado, alteraes nos requisitos so comuns e muitas vezes inevitveis.


49

ULBR

A E

duca

o a

Dist

nci

aO processo de Gerncia de Requisitos aborda as atividades seguintes ao processo de Produo de Requisitos, com etapas de:

Controle de mudanas;

Gerncia de confi gurao;

Rastreabilidade;

Qualidade de Requisitos.

Este processo de Gerncia de Requisitos ainda incomum junto a desenvolvedores de software dada sua complexidade e custo elevados. Entretanto, sua utilizao vem crescido ao longo do tempo junto com o crescimento das implementaes de modelos de maturidades de qualidade de software, como CMMI e MPS.BR, que formalmente os exigem desde os nveis mais iniciais. A constatao vigente de que no basta apenas levantar e registrar os requisitos para uso imediato pelos desenvolvedores, mas, principalmente, so necessrias etapas posteriores, que possibilitem sua correta gerncia, armazenamento e controle ao longo do tempo, seno, perde-se completamente seu valor em momentos de manuteno/evoluo do software.

A etapa de Controle de Mudanas encarregadas do controle dos requisitos em relao ao longo do tempo, controlando as mudanas ocorridas desde a sua criao. Um histrico de mudanas importante para poder identificar os autores das mudanas, seus motivos e o que efetivamente mudou nos requisitos. Esta uma tarefa bastante complicada para ser gerenciada manualmente, sendo indicado o uso de ferramentas computacionais especficas. O subprocesso do Controle de Mudanas inclui:

Verifi cao da validade da solicitao da mudana;

Identificao de todos os requisitos afetados na mudana e suas dependncias;

Estimar custos e prazos da mudana;

Obter aceite e aprovao da mudana.

A Gerncia de Configurao aborda os critrios de integridade no processo de manuteno dos requisitos, desde sua criao at seu descarte (somente aps o trmino da vida til do software). Define que seja desenvolvido um plano formalizado que inclua atores (pessoas), artefatos (documentos) e ferramentas.

A etapa de Rastreabilidade visa acompanhar todas mudanas sofridas por um requisito, mas no somente por ele, e sim por todos os demais requisitos envolvidos/relacionados. Normalmente utiliza-se uma matriz de rastreabilidade, em que os relacionamentos entre requisitos so modelados. Um exemplo clssico


50

ULBR

A E

duca

o a

Dist

nci

a da necessidade de controle de rastreabilidade em um sistema comercial d-se no controle da frmula de juros: no possvel alterar a frmula em apenas um mdulo (aquele que solicitou a alterao), mas sim em todos os demais que a utilizam, seno, provavelmente teremos, em diferentes partes do sistema, juros calculados de forma diferente, refletindo em relatrios e fechamentos que jamais estaro corretos, para completa desordem dos contadores.

A Qualidade dos requisitos descrita na norma IEEE 830, que aborda caractersticas como:

Correo;

No Ambiguidade;

Completude;

Consistncia;

Verifi cabilidade;

Modifi cabilidade.

A norma IEEE 830 tambm descreve uma estrutura genrica para um documento de requisitos, composto de:

Prefcio;

Introduo;

Glossrio;

Requisitos de usurio;

Arquitetura do sistema;

Requisitos de sistema;

Modelos de sistema;

Evoluo de sistema;

Apndices;

ndice.


51

ULBR

A E

duca

o a

Dist

nci

aAtividadesComplete com V (verdadeiro) ou F (falso) para as seguintes afirmaes:

Requisitos incompletos e falta de envolvimento do usurio so fatores crticos de sucesso no desenvolvimento de software porque 55% dos investimentos em desenvolvimento de software se concentram nesta rea.

Requisitos so importantes, porm, no estabelecem referncia para a validao do produto final.

Requisitos apresentam condio ou capacidade que deve ser alcanada para atender a uma especificao formal.

Requisitos de domnio so mais facilmente identificveis que requisitos funcionais e no funcionais.

A etapa de anlise e negociao de requisitos est diretamente relacionada com a anlise de viabilidade.

BibliografiaAVILA, Ana. SPINOLA, Rodrigo. Introduo Engenharia de Requisitos. Revista Engenharia de Software edio especial. 2007. Editora DevMidia. Disponvel em: http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-engenharia-de-requisitos/8034

GUSTAFSON, David. Engenharia de Software. Porto Alegre: Bookman, 2003.

PRESSMAN, Roger. Engenharia de Software, uma abordagem profissional. 7. Edio. Porto Alegre: McGraw-Hill/Bookman, 2011.

SCHACH, Stephen. Engenharia de Software: Os Paradigmas Clssico e Orientado a Objetos. 7. Edio. So Paulo: McGraw-Hill, 2009.

SOMMERVILLE, Ian. Engenharia de Software. 9. Edio. So Paulo: Pearson, 2011.

TONSIG, Srgio Luiz. Engenharia de Software Anlise e Projeto de Sistemas. So Paulo: Futura, 2003.

Gabarito:

F F V F V


52

ULBR

A E

duca

o a

Dist

nci

a


5 PROJETO E ARQUITETURA DE SOFTWARELus Fernando Fortes Garcia, prof. Dr.

ES - Engenharia de Software I

Documents

Transcript of ES - Engenharia de Software I