Processos de Software e Requisitos
Contents
1. Um modelo de processo de desenvolvimento de software uma representa o abstrata de um processo Ele apresenta uma descri o do processo de uma perspectiva em particular Prof Fl vio de Oliveira Silva Ph D 10 1 2015 10 1 2015 Descri es de processo de software Quando descrevemos e discutimos processos geralmente falamos sobre as atividades desses processos tais como especificac o de modelo de dados desenvolvimento de interface de usu rio etc e organiza o dessas atividades Descri es de processos tamb m podem incluir Y Produtos que s o os resultados de uma atividade do processo Y Pap is que refletem as responsabilidades das pessoas envolvidas no processo v Pr e p s condi es que s o declara es que s o verdadeiras antes e depois de uma atividade do processo ser executada ou um produto produzido ERES Modelagem de Software Prof Fl vio de Oliveira Silva Ph D Processos dirigidos a planos e geis Processos dirigidos a planos s o processos em que todas as atividades do processo s o planejadas com anteced ncia e o progresso medido em rela o a esse plano Nos processos geis o planejamento incremental e mais f cil modificar o processo para refletir altera es nos requisitos do cliente Na realidade os processos mais pr ticos incluem elementos dos processos geis e dirigidos a planos N o existe processo de software certo ou errado Modelagem de S2. Oliveira Silva Ph D 39 10 1 2015 Cerim nias Daily Scrum Meeting Ceremonies go SNCS vasi ES Ae rin nnin Parameters bs A 15 minutes St d Retrospective E vai fes Daily Scrum Not for problem solving Only team members Scrum Master product owner can talk Improve communications Eliminate other meetings identify and remove impediments to development UV UNS 9 IAVIV UG WIVUIGA VIIVO 9 Ile b e AGFA 4 HealthCare e cate cent Allianz Q HSBC 2 Autodesk ma oe EA ON Capgemini QS2EING BritishGas d pa opoh YAHOO intel SIEMENS ericsson amp Google Microsoft NOKIA tag Myspace SAP LEGO O ING amp DIRECT a place for friends amp TEIT McKinsey amp Company WIVUGIAYSCINI uuo vuIuvalu Prof Fl vio de Oliveira Silva Ph D 40 Pontos Importantes Os processos devem incluir atividades para lidar com mudan as O que pode envolver uma fase de protipa o que ajuda a evitar m s escolhas nos requisitos e no projeto Os processos devem ser estruturados para evolu o e entrega iterativa para que as mudan as possam ser feitas sem causar problemas ao sistema como um todo O Rational Unified Process um modelo de processo gen rico moderno organizado em fases concep o elabora o constru o e transi o mas que separa as atividades dessas fases requisitos an lise e projeto etc Modelagem de Software Prof Fl vio de Oliveira
3. Silva Ph D Prof Fl vio de Oliveira Silva Ph D 10 1 2015 41 10 1 2015 Requisitos de Software 2a Wall It s It s a Snake Prof Fl vio de Oliveira Silva Ph D Engenhari O processo de estabelecer os Se VICOS que o cliente necessita do sistema e as restri es sob as quais ele opera e desenvolvido Os pr prios requisitos s o as descri es dos servi os do sistema e restri es geradas durante o processo de engenharia de requisitos Prof Fl vio de Oliveira Silva Ph D 42 O que um requisito Pode variar de uma declara o abstrata de alto n vel de um servi o ou de uma restri o do sistema para uma especifica o matem tica funcional Isso inevit vel quando os requisitos podem servir a uma fun o dupla Pode ser a base para a proposta de um contrato portanto deve ser aberto interpreta o Pode ser a base para o contrato em si portanto deve ser definido em detalhe Ambas as declara es podem ser chamadas de requisitos Prof Fl vio de Oliveira Silva Ph D Ti Requisitos de usu rio v Declara es em linguagem natural com diagramas dos servi os que o sistema dever fornecer e suas restri es operacionais Escrito para os clientes Requisitos de sistema v Um documento estruturado estabelecendo descri es detalhadas das fun es do sistema servi os e restri es operacionais Define o que deve ser implementado as
4. Whew mex displaying a thumbnail of the property and classifiers arid their values if the value has been set Delete image A lser must be able W delete An image from tha Tessera DOHC and should be Prompted as to whal listings the image is related to 2 Classifiers A The name of the default classifiers already defined by the system are city type d real estate values can be house condo or townhouse nec range e adbuc to market date ai which real estate was put on the market Prof Fl vio de Oliveira Silva Ph D 10 1 2015 45 10 1 2015 Impreci Problemas surgem quando os requisitos n o s o precisamente definidos Requisitos amb guos podem ser interpretados de maneiras diferentes por desenvolvedores e usu rios Considere o termo pesquisa no requisito 1 es v A inten o do usu rio busca pelo nome de um paciente em todos as consultas em todas as cl nicas eres Interpreta o do desenvolvedor busca pelo nome de um paciente em uma cl nica O usu rio escolhe a cl nica e em seguida pesquisa ae etree Ne e Modelagem de Software Prof Fl vio de Oliveira Silva Ph D Esses requisitos definem as propriedades e as restri es do sistema por exemplo confiabilidade tempo de resposta e ocupa o de rea As restri es s o capacidades de dispositivos de E S as representa es do sistema etc Os requisitos de processo tamb m podem ser especificados impond
5. Y Desenvolvimento e integra o Atualmente o re so a abordagem padr o para a constru o de v rios tipos de sistemas de neg cio Modelagem de Software Prof Fl vio de Oliveira Silva Ph D Engenharia de software orientada a re so Especifica o An lise de Altera es nos Projeto de sistema sa no de requisitos componentes requisitos com re so Desenvolvimento Valida o e integra o de sistema Prof Fl vio de Oliveira Silva Ph D 14 10 1 2015 Tipos de componente de software Web services que s o desenvolvidos de acordo com padr es de servi o e ficam dispon veis para chamada remota Cole es de objetos que s o desenvolvidas como um pacote para ser integrado com um framework como NET ou J2EE Sistemas de software stand alone COTS que s o configurados para uso em ambientes espec ficos Modelagem de Software Prof Fl vio de Oliveira Silva Ph D Atividades do processo Processos de software reais s o sequ ncias intercaladas de atividades t cnicas colaborativas e gerenciais com o objetivo geral de especificar projetar implementar e testar um sistema de software As quatro atividades de processo b sicas especifica o desenvolvimento valida o e evolu o s o organizadas de forma diferente em processos de desenvolvimento distintos No modelo cascata elas s o organizadas em sequ ncias enquanto no desenvolvimento incremental s o intercaladas
6. example show a thombnaal of ihe selected image 1 1 3 After the user selects the image the user can classify the image by giving values to uns number of classifiers L14 The user can only insert onc picture ai a lume I 5 The Wser ds allow eil Ler inser the ume image into the hep boy many Limes Li Image formats supported by the system are jpg png and gif Li When the user oploads am image to the repository a copy of the image 13 mode ard saved in the e prosa to LIAL When the user uploads am image do the repository a thumbnail format of the copied image is created and saved in ihe repository LES User can add comments bo images in Search repxrsibomry for image s LZ Search musi be accessible rem all levels 22 User con search the repository based on classifiers and their desired values example city Vancouver r citys 123 Classifier values for searches can be of nny value use or of no value 1 24 User can advance search the repository using kegical connectives such as and and or example cliy Vancouver OR oliy New Wesbminster AND type of real estate Tovenbosce 2 5 When advange E searching the user cur mb other c lassifiers ti the search query aml tbe pertinent value that is desired for the search The search query is connected using logical connectives L26 When the user searches the repository a list of properties that matches the parame in the query ds pey galad user goes Bo
7. of players in a scrum P pP i Serum x ScrumAlliance LS ad yo serum Serum Logo liii i li UT ji I Prof Fl vio de Oliveira Silva Ph D Scrum Overview Daily Scrum Meeting Backlog tasks expanded Sprint Backlog by team Potentially Shippable Product Backlog Product Increment As prioritized by Product Owner Source Adaghed tram Age Solar D evelboment wih Scrum by Ken Schwaber and Mike Drede Modelagem de Software Prof Fl vio de Oliveira Silva Ph D 35 10 1 2015 produ Revenant Rather than doing all of one thing at a time Scrum teams do a little o everything all the time SPRINT Source The New Product Development Game by Takeuchi and Nonaka Harvard Business Review January 1986 Prof Fl vio de Oliveira Silva Ph D Mudancas durante o Sprint SPRINT Shippable The Scrum Master ensures that no changes are made that would affect the sprint goal WIVUGIAYOIN UG v UUNILVVOI G Prof Flavio de Oliveira Silva Ph D 36 10 1 2015 Framework SCRUM Ceremonies Sprint Planning Artifacts Product Owner Product backlog Sprint Review Scrum Master Sprint Backlog Sprint Retrospective Burn Down Daily Scrum Meeting Prof Fl vio de Oliveira Silva Ph D ds as Product Owner Define the features of the product Product Backlog owner Decide on release date and content Be responsible for the profitabil
8. ou ferramentas de prototipagem r pida Pode deixar a funcionalidade de fora do teste Y A prototipa o deve focar em reas do produto que n o s o bem entendidas v Y A checagem de erros e recupera o podem n o estar inclu das no prot tipo V O foco deve ser em requisitos funcionais ao inv s de n o funcionais como por exemplo a confiabilidade e a seguran a Modelagem de Software Prof Fl vio de Oliveira Silva Ph D Descarte de prot tipos Os prot tipos devem ser descartados depois do desenvolvimento pois n o s o uma boa base para um sistema em produ o v Pode ser imposs vel ajustar o sistema para alcan ar requisitos n o funcionais Y Geralmente os prot tipos n o possuem documenta o Y Geralmente a estrutura do prot tipo degradada por mudan as r pidas Y Provavelmente o prot tipo n o ir alcan ar os padr es normais de qualidade organizacional Prof Fl vio de Oliveira Silva Ph D 25 10 1 2015 Entrega incremental Ao inv s de entregar o sistema em uma nica entrega o desenvolvimento e a entrega sao distribu dos em incrementos nos quais cada incremento entrega parte da funcionalidade necess ria Os requisitos do usu rio s o priorizados e os requisitos de mais alta prioridade sao inclu dos nos primeiros incrementos Assim que o desenvolvimento de um incremento iniciado os requisitos s o congelados mas os requisitos dos incrementos posteriores podem cont
9. 10 1 2015 Atividades t picas do processo de desenvolvimento o Elicita o de Requisitos Qual o problema ms O que ser feito o An lise e projeto de software m Como ser feito m Descri o computacional Projeto de arquitetura e detalhado o Implementa o o Testes o Implanta o Modelagem de Software Prof Fl vio de Oliveira Silva Ph D Modelo Linear Cascata Waterfall O resultado de cada fase envolve documentos que devem ser validad A fase seguinte n o deve inicie at que a fase anterior termine Problema inflex vel divis o em fases distintas Funciona apenas quando os requisitos forem bem entendidos 10 1 2015 Modelo Linear cr tica Projetos reais raramente seguem o fluxo sequencial Em projetos grandes impossivel elicitar todos os requisitos antes da fase de an lise Requisitos s o frequentemente alterados o que impacta na an lise e projeto Demora na descoberta de erros Espera por fim de uma fase para iniciar outra bloqueio Prof Fl vio de Oliveira Silva Ph D Desenvolvimento iterativo e incremental Diversos passos itera es com adi o de funcionalidades incremental Requisitos s o agrupados por funcionalidade e implementados em um ciclo de desenvolvimento Partes do software s o entregues baseado em requisitos priorit rios Requisitos com maiores riscos s o atacados primeiro Prof Fl vio de Oliveira Silva Ph D 10 1 2015 Modelo em espiral
10. Dctcrmina Objetivos Alternativas Restri es e g Comprometimento 2 parti o Plancja a pr xima fase AC usto Acumulado Progresso atrav s das fases Avalia alternativas identifica e resolvo risc s An lise de Riscos Plano de Requisitos Plano do Ciclo de Vida Id ia dc Plano de Requisitos dc Desenvoly imento Valida I jeto da Plano de Testes Verifica o c i Plano de Integra o Valida o i i Teste Ti i Desenvolve c verifica o produto no nivel S gu Iniegra o l I Teste i l 1 I Aceita o Lu l Implementa o 1 l Prof Fl vio de Oliveira Silva Ph D Modelo em espiral o Cada loop dividido em 4 setores Defini o de objetivos Avalia o e redu o de riscos Desenvolvimento e valida o Planejamento Prof Fl vio de Oliveira Silva Ph D 10 1 2015 Metodologias geis o conceitos chave do Manifesto gil Indiv duos e intera es ao inv s de processos e ferramentas Software execut vel ao inv s de documenta o Colabora o do cliente ao inv s de negocia o de contratos Respostas r pidas a mudan as ao inv s de seguir planos o Ex Extreme Programming XP Scrum Prof Fl vio de Oliveira Silva Ph D Extreme Programming o A Extreme Programming XP uma metodologia gil para equipes pequenas e m dias que desenvolvem software baseado em requisitos vagos e que se modificam rapidamente Hn D
11. Prof Fl vio de Oliveira Silva Ph D 15 Especifica es de software e O processo de estabelecer quais servi os s o necess rios e as restri es na operacao e desenvolvimento do sistema Processo de engenharia de requisitos v Estudo de viabilidade E t cnica e financeiramente vi vel construir o sistema Y Elicitacdo e an lise de requisitos O que os stakeholers do sistema precisam ou esperam do sistema Y Especifica o de requisitos Defini o dos requisitos em detalhes Y Valida o de requisitos Prof Fl vio de Oliveira Silva Ph D O processo de engenharia de requisitos Estudo da Elicitac o e an lise 1 viabilidade de requisitos Especifica o de requisitos Relat rio Valida o de viabilidade de requisitos Modelos de sistema Requisitos de usu rios e de sistema o Documenta o de requisitos Prof Fl vio de Oliveira Silva Ph D 10 1 2015 16 10 1 2015 Projeto e implementa o de software O processo de converter a especifica o de sistema em um sistema execut vel Projeto de software Y Design de uma estrutura de software que materialize a especifica o Implementa o v Transformar essa estrutura em um programa execut vel As atividades de projeto e implementa o s o intimamente ligadas e podem ser intercaladas Viodelagem de Software Prof Fl vio de Oliveira Silva Ph D Modelo geral do processo de design Entrada
12. ade de acomoda o de mudan as depois que o processo j foi iniciado Em princ pio uma fase precisa ser completada antes de se mover para a pr xima fase delagem Prof Fl vio de Oliveira Silva Ph D 10 1 2015 11 Problemas do modelo cascata 10 1 2015 e Divis o inflex vel do projeto em est gios distintos torna dif cil responder as mudan as nos requisitos do cliente V Por isso esse modelo s apropriado quando os requisitos s o bem entendidos e as mudan as durante o processo de projeto ser o limitadas V Poucos sistemas de neg cio possuem requisitos est veis e O modelo cascata mais usado em projetos de engenharia de grandes sistemas onde o sistema desenvolvido em v rios locais v Nessas circunst ncias a natureza do modelo cascata dirigida a planos ajuda a coordenar o trabalho Modelagem de Software Prof Fl vio de Oliveira Silva Ph D Desenvolvimento incremental Atividade simult neas Especifica o Desenvolvimento I Valida o Descri o do esbo o Prof Fl vio de Oliveira Silva Ph D Vers o inicial Vers es intermedi rias Vers o final 12 10 1 2015 Benef cios do desenvolvimento incremental e O custo para acomodar mudan as nos requisitos do cliente reduzido v A quantidade de an lise e documenta o que precisa ser feita bem menor do que o necess ria no modelo cascata e mais f cil obter fe
13. ados delagem d Prof Fl vio de Oliveira Silva Ph D 21 Problemas da entrega incremental e A maioria dos sistemas requer um conjunto de fun es b sicas que s o usadas por diferentes partes do sistema Y Como os requisitos n o s o definidos em detalhes at que um incremento seja implementado pode ser dif cil identificar fun es comuns que s o necess rias a todos os incrementos A ess ncia dos processos iterativos que a especifica o seja desenvolvida em conjunto com o software Y No entanto essa pode entrar em conflito com o modelo de aquisi o de muitas organiza es nos quais a especifica o completa do sistema parte do contrato de desenvolvimento do sistema Modelagem de Software Prof Fl vio de Oliveira Silva Ph D Modelo espiral de Boehm O processo representado como uma espiral ao inv s de uma sequ ncia de atividades com retornos Cada loop na espiral representa uma fase do processo N o existem fases fixas como especifica o ou projeto os loops na espiral s o escolhidos de acordo com a necessidade Os riscos s o avaliados explicitamente e resolvidos no decorrer do processo Prof Fl vio de Oliveira Silva Ph D 10 1 2015 26 10 1 2015 O modelo de processo de software espiral de Boehm Determinar objetivos alternativas e restri es REVIS O Plano de requisitos Plane de ciclo de vida Plane de Valida o Avaliar alternativas iden
14. backlog Business conditions Current product nd ME s Daily meetings Sprint revi Sprint Backlog Sprint _ meeting DODO 4 weeks EE Beg mo EAEE ENA Cerim nias Sprint planning meeting Sprint prioritization Analyze and evaluate product backlog Select sprint goal Sprint planning Decide how to achieve sprint goal design Create sprint backlog tasks from product backlog items user stories features Estimate sprint backlog in hours Te Wed Thu iew Ceremonies Sprint Planning Sprint Review Sprint Daily Scrum Meeting j Sprint backlog Prof Fl vio de Oliveira Silva Ph D 38 10 1 2015 Cerimonias Sprint Review This is a 4 hour time boxed meeting for one month Sprints Ceremonies Sprint Planning Typically takes the form of a demo of new features or underlying architecture Sprint Retrospective The Product Owner identifies what has been done ia and what hasn t been done Daily Scrum Meeting The Team discusses what went well during the Sprint and what problems it ran into and how it solved these problems Sprint Review d Team presents what it accomplished during the sprint Cerim nias Sprint Retrospective Whole team gathers and discusses what they d like to Sprint Review Start doin g Sprint _ Retrospective 5 Daily Scrum Stop doing Continue doing Ceremonies Prof Fl vio de
15. cust ncias do neg cio o software que d suporte ao neg cio tamb m deve evoluir e mudar Apesar de ter acontecido uma demarca o entre desenvolvimento e evolu o manuten o essa precisa se tornar cada vez mais irrelevante j que tem diminu do a quantidade de sistemas completamente novos delagem d Prof Fl vio de Oliveira Silva Ph D 10 1 2015 20 10 1 2015 Evolu o do sistema Definir requisitos Avaliar sistemas Propor mudan as Modificar de sistema existentes de sistema sistemas Sistemas Novo sistema existentes lelagem de Software Prof Fl vio de Oliveira Silva Ph D Pontos Importantes e Os processos de software s o as atividades envolvidas na produ o de um sistema de software Os modelos de processo de software s o representa es abstratas desses processos Modelos de processo gerais descrevem a organiza o dos processos de software Exemplos desses processos gerais incluem o modelo cascata desenvolvimento incremental e desenvolvimento orientado a re so A engenharia de requisitos o processo de desenvolver uma especifica o de software Prof Fl vio de Oliveira Silva Ph D 21 10 1 2015 Pontos Importantes Processos de projeto e implementa o se preocupam em transformar uma especifica o de requisitos em um sistema de software execut vel A valida o de software o processo de checar se o sistema est em conformidade com sua especifica
16. edback do cliente sobre o trabalho de desenvolvimento que tem sido feito Y Os clientes podem comentar demonstra es do software e ver quanto foi implementado Possibilidade de mais rapidez na entrega e implanta o de software util para o cliente Y Os clientes podem usar e obter ganhos do software mais cedo do que poss vel no processo cascata cu Modelagem de Software Prof Fl vio de Oliveira Silva Ph D Problemas do desenvolvimento incremental e O processo n o vis vel Y Gerentes precisam de entregas regulares para medir o progresso Se os sistemas s o desenvolvidos de forma r pida n o vi vel do ponto de vista do custo produzir documenta o para refletir todas as vers es do sistema A estrutura do sistema tende a degradar conforme novos incrementos s o adicionados Y A menos que tempo e dinheiro sejam gastos na reconstru o para melhorar o software as mudan as regulares tendem a corromper a estrutura do sistema A incorpora o posterior de mudan as no software se torna progressivamente mais dif cil e cara Modelagem de Software Prof Fl vio de Oliveira Silva Ph D 13 10 1 2015 Engenharia de software orientada a re so Baseada no re so sistem tico em que os sistemas s o integrados com componentes existentes ou sistemas COTS Commercial off the shelf Est gios do processo Y An lise de componentes Y Modifica o de requisitos Y Projeto de sistema com re so
17. erspectiva est tica que mostra atividades do processo Y Uma perspectiva pr tica que sugere boas pr ticas Viodelagem de Software Prof Fl vio de Oliveira Silva Ph D Fases no Rational Unified Process Itera o de fase Cocos Ea Concep o Elabora o Constru o Transi o delagem d Prof Fl vio de Oliveira Silva Ph D 10 1 2015 30 10 1 2015 Rational Unified Process RUP Workflows Business Modeling Requirements Analysis amp Design Implementation Test Deployment Configuration amp Change Mgmt Project Management Environment D EE CNJ Iterations Modelagem de Software Prof Fl vio de Oliveira Silva Ph D Rational Unified Process RUP Fases Modelagem de Neg cios Requisitos o An lise e Design O Implementa o B Teste a Implanta o g Gerenciamento de Configura o e Mudan as Gerenciamento de Projetos B Ambiente itera es Prof Fl vio de Oliveira Silva Ph D 31 10 1 2015 Fases do RUP Concep o ou inicia o Y Estabelece o business case para o sistema Elabora o Y Desenvolve um entendimento da extens o do problema e da arquitetura do sistema Constru o V Projeta o sistema programa e testa o sistema Transi o Y Implanta o sistema no seu ambiente de opera o Modelagem de Software Prof Fl vio de Oliveira Silva Ph D Itera o do RUP e teracao Intra fase v Cada fase itera
18. haria de Software o PROJETO Como o software ir executar os requisitos Estrutura de dados Arquitetura do Software Detalhes de execu o caracteriza o da interface Produzir um modelo que permita a sua constru o posterior o PROJETO ESTRUTURADO M dulos o PROJETO ORIENTADO A OBJETOS Atributos Especifica o dos M todos Mensagens n Diagramas de Sequ ncia Diagrama de Classes Prof Fl vio de Oliveira Silva Ph D Engenharia de Software o CODIFICA O Traduzir o projeto para uma linguagem de computador m Projeto detalhado pode levar a uma codifica o mec nica Ferramenta CASE o TESTES m Verifica o se o c digo atende aos requisitos m Aspectos l gicos e internos do software Teste de todas as instru es m Aspectos funcionais externos entrada produz o resultado esperado Prof Fl vio de Oliveira Silva Ph D 10 O modelo cascata Definicao de requisitos Projeto de sistema e software Implementacao e teste unit rio Integra o e teste de sistema Opera o e manuten o delagem de Software Prof Fl vio de Oliveira Silva Ph D Fases do modelo cascata e Existem fases identificadas e separadas no modelo cascata Y An lise e defini o de requisitos v Projeto de sistema e software Y Implementa o e teste de unidade Y Integra o e teste de sistema Y Opera o e manuten o e O principal inconveniente do modelo cascata a dificuld
19. iferenciais m Feedback constante Abordagem incremental A comunica o entre as pessoas encorajada o 12 pr ticas Prof Fl vio de Oliveira Silva Ph D 10 1 2015 Algumas pr ticas da XP Entregas frequentes Projeto simples Programa o em pares Propriedade coletiva Integra o cont nua C digo padronizado Modelagem Prof Fl vio de Oliveira Silva Ph D Ferramentas CASE Computer Aided Software Engineering Ferramentas que auxiliam d o suporte as atividades de um processo de desenvolvimento de software Ex editores de modelos compiladores depuradores de c digo gerenciadores de configura o ferramentas de teste ambientes de desenvolvimento Prof Fl vio de Oliveira Silva Ph D Uso de ferramentas CASE na disciplina Hn StarUML ArgoUML RationalRose Astah Qualquer outra que o grupo quiser LI Li LI Li Modelagem de Software Prof Fl vio de Oliveira Silva Ph D O processo de software Um conjunto estruturado de atividades necess rias para desenvolver um sistema de software Existem v rios processos de desenvolvimento de software diferentes mas todos envolvem especifica o defini o do qu o sistema deve fazer projeto e implementa o defini o da organiza o do sistema e implementa o do sistema valida o checagem de que o sistema faz o que o cliente deseja evolu o evolu o em resposta a mudan as nas necessidades do cliente
20. inuar a evoluir Modelage Prof Fl vio de Oliveira Silva Ph D Desenvolvimento e entrega incremental e Desenvolvimento incremental Y Desenvolve o sistema em incrementos e avalia cada incremento antes de proceder com o desenvolvimento do pr ximo incremento v Abordagem normalmente usada em m todos geis Y Avalia o feita por representantes do usu rio cliente Entrega incremental Y mplanta um incremento para uso do usu rio final v Avalia o mais real stica sobre o uso pr tico do software Y Dif cil de implementar para sistemas substitutos devido aos incrementos que est sendo substituido Prof Fl vio de Oliveira Silva Ph D 26 10 1 2015 Entrega incremental Definir esboco Atribuir requisitos Projetar arquitetura Desenvolver incrementos de requisitos aos incrementos de sistema de sistema Sistema incompleto Validar Integrar Eg Implantar l E 9 X Validarsistema p incrementos incrementos incrementos Sistema completo Sistema final Viodelagem de Software Prof Fl vio de Oliveira Silva Ph D Vantagens da entrega incremental Os valores podem ser entregues ao cliente junto com cada incremento e fun es do sistema ficam dispon veis mais r pidamente Primeiros incrementos agem como prot tipos para ajudar a deduzir requisitos para incrementos posteriores Menor risco de falha geral do projeto Os servi os mais priorit rios do sistema tendem a serem mais test
21. ity of the product ROI Prioritize features according to market value Adjust features and priority every iteration as needed Accept or reject work results He can cancel an Sprint Scrum Master Represents management to the project Responsible for enacting Scrum values and practices Removes impediments Ensure that the team is fully functional and productive Enable close cooperation across all roles and functions Shield the team from external interferences A Scrum Master should never be the Product owner Prof Fl vio de Oliveira Silva Ph D Team Typically 7 people 2 Cross functional team Teams are self organizing Membership should change only between sprints Turns the product backlog into increments of porcus shippable unctionality Show the deliverables to the product owner 37 Artefatos 10 1 2015 Product Backlog Sample Sprint Backlog sample sprint Burndown Chart Backlog item Estimate Li VD Mow apestomates Tasks E ES RE servati TENE Code the user interfac stats As a guest want to cancel a E danado Code the middle tier nnnna As a guest want to change the dates of a reservation Test the middle tier suspen s As a hotel employee can run i RevPAR reports revenue per 8 Write online help ill available room Improve exception handing 8 Writethe food class OPPE e Team capacity Product
22. ma O teste a atividade de V amp V mais usada Prof Fl vio de Oliveira Silva Ph D 18 Est gios de teste NEN Teste de componente Teste desistema Teste de aceita o Prof Fl vio de Oliveira Silva Ph D Est gios de teste e Teste de desenvolvimento ou de componente Y Componentes individuais s o testados independentemente v Componentes podem ser fun es ou objetos ou agrupamentos coerentes dessas entidades e Teste de sistema v Teste do sistema como um todo Teste de propriedades emergentes s o particularmente importantes Teste de aceita o Y Teste com dados do cliente para checar se o sistema est de acordo com as necessidades do cliente Prof Fl vio de Oliveira Silva Ph D 10 1 2015 19 Fases de teste em um processo de software dirigido a planos Especifica o Especifica o de requistos de sistema d d d do Plano de testes Plano de teste C digo e teste de integra o de integra o unit rio e de sistema do subsistema de m dulo RM Teste de integrac o Teste de integra o lt de sistema de subsistema gt Projeto de sistema Projeto detalhado Plano de testes de aceita o Opera o Teste de aceita o Modelagem de Software Prof Fl vio de Oliveira Silva Ph D Evolu o do software Os softwares s o inerentemente flex veis e podem mudar Conforme os requisitos mudam conforme mudam as cir
23. mento N mero de frames de ajuda Confiabilidade Tempo m dio para falha Probabilidade de indisponibilidade Taxa de ocorr ncia de falhas Disponibilidade Robustez Tempo de rein cio ap s falha Percentual de eventos que causam falhas Probabilidade de corrup o de dados em caso de falha Portabilidade Percentual de declara es dependentes do sistema alvo N mero de sistemas alvo Prof Fl vio de Oliveira Silva Ph D Especifica o de requisitos O processo de escrever os requisitos de usu rio e de sistema em um documento de requisitos Os requisitos precisam ser compreens veis para usu rios finais e clientes que n o t m forma o t cnica Requisitos de sistema s o mais detalhados e podem incluir informa es mais t cnicas Os requisitos podem ser parte de um contrato para o desenvolvimento do sistema v Portanto importante que esses Prof Fl vio de Oliveira Silva Ph D 49 10 1 2015 Pr requisi Em princ pio os requisitos devem indicar o que o a sistema deve fazer e o projeto deve descrever como fazer isso Un a T RE Na pr tica os requisitos e o projeto s o insepar veis v A arquitetura do sistema pode ser projetada para estruturar os requisitos vO sistema pode interoperar com outros sistemas que restringem o projeto e imp em requisitos sobre o novo sistema O uso de uma arquitetura espec fica para satisfazer os requisitos n o funcionais pode ser um requisito de dom
24. nio Prof Fl vio de Oliveira Silva Ph D Diretrizes para escrever requisitos DEFINIR um formato padr o e us lo para todos os requisitos e Usar a linguagem de uma forma consistente Reg ticle Writing p Guidelines Usar deve para requisitos obrigat rios e pode para os requisitos desej veis Usar o realce de texto para identificar as partes fundamentais do requisito Evitar o uso de jarg es de computador Incluir uma justificativa l gica de por que um requisito necess rio Prof Fl vio de Oliveira Silva Ph D 50 10 1 2015 O processo de elicita o e an lise de 1 Descoberta de requisitos 2 Classifica o e organiza o de requisitos 4 Especifica o de requisitos 3 Prioriza o e negocia o de 22 requisitos Se de Software ivi s avio de Oliveira Silva Ph D 51
25. o e se esse est de acordo com as necessidades reais do usu rio do sistema A evolu o de software ocorre quando voc altera sistemas de software existentes para adequ los a novas necessidades O software precisa evoluir para continuar til Modelagem de Software Prof Fl vio de Oliveira Silva Ph D Lidando com mudan as e As mudan as s o inevit veis em todos grandes projetos de software Y Mudan as no neg cio levam a novos e diferentes requisitos de sistema v Novas tecnologias abrem novas possibilidades para melhorar implementa es Y Mudan as de plataforma requerem mudan as na aplica o e As mudan as geram retrabalho o que faz com que o custo das mudan as inclua o retrabalho p ex rean lise dos requisitos assim como o custo de implementa o de novas fun es Prof Fl vio de Oliveira Silva Ph D 22 10 1 2015 Reduzindo o custo de retrabalho e Preven o de mudan as quando o processo de software inclui atividades que podem antecipar poss veis mudan as antes que o retrabalho se torne necess rio v Por exemplo um prot tipo de sistema pode ser desenvolvido para mostrar algumas caracter sticas fundamentais do sistema para os clientes Toler ncia a mudan as quando o processo desenvolvido para que mudan as possam ser acomodadas a um custo relativamente baixo Y Geralmente envolve alguma forma de desenvolvimento incremental As mudan as propostas podem ser implementada
26. o um IDE particular linguagem de programa o ou m todo de desenvolvimento Os requisitos n o funcionais podem ser mais cr ticos do que os requisitos funcionais Se esses n o forem atendidos o sistema pode ser in til Prof Fl vio de Oliveira Silva Ph D 46 Requisitos n o funcionais Requisitos Requisitos Requisitos de produto Requisitas Requisitos de efici ncia de confian a reguladores de prote o Requisitos de desenvolvimento Requisitos Requisitos Requisitos de usabilidade ambientals operacionais Requisites Requisitos Requisitas de desempenho de espa o cont beis Prof Fl vio de Oliveira Silva Ph D Implementa o de FEQUISITO nao funcional CourseService StudentService Audit Advice Requisitos n o funcionais podem afetar a arquitetura geral de um sistema em vez de componentes individuais MiscService v Por exemplo para assegurar que os requisitos de desempenho sejam cumpridos voc pode ter que organizar o sistema para minimizar a comunica o entre os componentes Um nico requisito n o funcional como um requisito de prote o pode gerar uma s rie de requisitos funcionais relacionados que definem os servi os do sistema que s o necess rios Ele tamb m pode gerar requisitos que restringem os requisitos existentes Prof Fl vio de Oliveira Silva Ph D organizacionais externos Requisitos Requisitos Requisitos Requisitos legais Requisit
27. oftware Prof Fl vio de Oliveira Silva Ph D 10 1 2015 Modelos de processo de software Modelo Cascata Modelo dirigido a planos Fases de especifica o e desenvolvimento separadas e distintas Desenvolvimento Incremental Especifica o desenvolvimento e valida o s o intercaladas Pode ser dirigido a planos ou gil Engenharia de software orientada a re so O sistema montado a partir de componentes j existentes Pode ser dirigido a planos ou gil Na realidade a maioria dos grandes sistemas s o desenvolvidos usando um processo que incorpora elementos de todos esses modelos Modelagem de Software Prof Fl vio de Oliveira Silva Ph D Ciclo de Vida Modelo Cascata TESTE MANUTEN O Prof Fl vio de Oliveira Silva Ph D 10 1 2015 Engenharia de Software o ENGENHARIA DE SISTEMAS Levantamento dos requisitos Inserir o sistema em um contexto maior Hardware Pessoas Outros sistemas Vis o geral e ampla do sistema Riscos Custos Prazos Planejamento Prof Fl vio de Oliveira Silva Ph D Engenharia de Software o AN LISE Continua o processo de coleta de requisitos por m concentra se no mbito do software Modelos Dados Fun es e comportamentos Particionamento do problema Documenta o e Revis o dos requisitos n AN LISE ESTRUTURADA DFD o AN LISE ORIENTADA A OBJETOS Diagramas de Caso Uso Prof Fl vio de Oliveira Silva Ph D 10 1 2015 Engen
28. os de seguran a prote o 10 1 2015 47 10 1 2015 Classifica es de requisitos n o funcionai Requisitos de produto v Requisitos que especificam que o produto entregue deve se comportar de uma maneira particular por exemplo velocidade de execu o confiabilidade etc Requisitos organizacionais v Requisitos que s o consequ ncia de pol ticas e procedimentos organizacionais por exemplo padr es de processo usados requisitos de implementa o etc Requisitos externos v Requisitos que surgem de fatores externos ao sistema e seu processo de desenvolvimento por exemplo requisitos de reguladores requisitos odelagem Prof Fl vio de Oliveira Silva Ph D r Requisitos n o funcionais podem ser muito dif ceis de se definir precisamente e requisitos imprecisos podem ser dif ceis de se verificar Metas v A inten o geral do usu rio facilmente us vel Requisito n o funcional mensur vel v Uma declara o usando alguma m trica que pode ser objetivamente testada Metas s o teis para desenvolvedores quando exprimem as inten es dos usu rios do sistema Prof Fl vio de Oliveira Silva Ph D 48 10 1 2015 M tricas para especificar requisitos AJ e dU JNCIQOTIo Velocidade Transa es processadas segundo Tempo de resposta de usu rio evento lempo de atualiza o de tela Tamanho Megabytes N mero de chips de mem ria ROM Facilidade de uso Tempo de treina
29. s de projeto Informa o Especifica o Descri o de plataforma de requisitos de dados Atividades de projeto Projeto de Projeto de Projeto de arquitetura interface componentes Projeto de banco de dados Sa das de projeto Arquitetura Especifica o de Especifica o Especifica o de sistema banco de dados de interface de componentes delagem Prof Fl vio de Oliveira Silva Ph D 17 10 1 2015 Atividades de projeto Projeto de arquitetura em que voc identifica a estrutura geral do sistema os componentes principais as vezes chamados sub sistemas ou m dulos seus relacionamentos e como s3o distribu dos Projeto de interface em que voc define as interfaces entre os componentes do sistema Projeto de componente em que voc projeta como cada componente do sistema ir operar separadamente Projeto de banco de dados em que voc projeta as estruturas de dados do sistema e como essas ser o representadas no banco de dados Modelagem de Software Prof Fl vio de Oliveira Silva Ph D Valida o de software Verifica o e valida o V amp V serve para mostrar que o sistema est em conformidade com sua especifica o e est de acordo com os requisitos do cliente Envolve processos de inspe o e revis o e testes do sistema Testes do sistema envolvem executar o sistema com casos de teste S o provenientes de especifica es dos dados reais que dever o ser processados pelo siste
30. s em incrementos que ainda n o foram desenvolvidos Se isso imposs vel ent o um incremento nico uma pequena parte do sistema pode ser alterada para incorporar a mudan a Modelagem de Software Prof Fl vio de Oliveira Silva Ph D Prototipa o de software e Um prot tipo uma vers o inicial de um sistema usada para demonstrar conceitos e testar op es de projeto Um prot tipo pode ser usado v No processo de engenharia de requisitos para ajudar na elicita o e valida o de requisitos v Nos processos de projeto para explorar op es e desenvolver um projeto de interface de usu rio v No processo de testes para executar testes fim a fim Modelagem de Software Prof Fl vio de Oliveira Silva Ph D 23 Benef cios da prototipa o Melhoria do uso do software Maior proximidade com as necessidades do usu rio Melhorias na qualidade do projeto Maior manutenibilidade Reduzir esfor os de desenvolvimento delagem de Software Prof Fl vio de Oliveira Silva Ph D O processo de desenvolvimento de prot tipo Estabelecer Definir objetivos funcionalidade do do prot tipo prot tipo Desenvolver prot tipo NN Plano de Definici Prot tipo Relat rio de prototipa o dd ae execut vel avalia o gt Avaliar o prot tipo Prof Fl vio de Oliveira Silva Ph D 10 1 2015 24 10 1 2015 Desenvolvimento de prot tipos Pode ser baseado em linguagens
31. sim pode ser parte de um contrato entre o cliente e o empreiteiro Prof Fl vio de Oliveira Silva Ph D 10 1 2015 43 10 1 2015 Especifica o de requisitos defistema 1 O MHC PMS deve gerar relat rios gerenciai 1 1 No ultimo dia til de cada m s deve ser mensais que mostrem o custo dos medicamentos gerado um resumo dos medicamentos prescritos por cada cl nica durante aquele m s prescritos seus custos e as prescri es de cada clinica 1 2 Ap s 17 30h do ltimo dia til do m s o sistema deve gerar automatic o relat rio para impress o 1 3 Um relat rio ser criado para cada cl nica listando os pomes dos medicamentos Pp n mero total de prescri es o n mero de doses prescritas e o custo total dos medicamentos prescritos 1 4 Se os medicamentos est o dispon veis em diferentes unidades de dosagem por exemplo 10 mg 20 mg devem ser criados relat rios separados para cada unidade 1 5 O acesso aos relat rios de custos deve ser restrito a rios autoriza por uma lista 7 de controle de gerenciamento de acesso lo delagem uc oOuUitwaic Prof Fl vio de Oliveira Silva Ph D Leitores de diferentes tipos de especifica o de requisitos Gerentes clientes Usu rios finais do sistema Engenheiros clientes Gerentes contratantes Arquitetos de sistema Requisitos de usu rio Usu rios finais do sistema Requisitos Engenheiros clientes de sistema Arquitetos de sistema Desenvolvedores de
32. software Prof Fl vio de Oliveira Silva Ph D 44 Requisitos funcionais e n o Requisitos funcionais v O sistema deve fornecer declara es de servi os como o sistema deve reagir a entradas espec ficas e como o sistema deve se comportar em determinadas situa es Pode explicitar o que o sistema n o deve fazer Requisitos n o funcionais v Restri es aos servi os ou fun es oferecidas pelo sistema tais como restri es de tempo restri es no processo de desenvolvimento padr es Muitas vezes se aplica ao sistema como um todo ao inv s de caracter sticas individuais ou servi os Modelagem de So ware Prof Fl vio de Oliveira Silva Ph D Functional Requirements Requisitos Funcionais Descrever a funcionalidade ou os servi os do sistema Depende do tipo de software poss veis usu rios e o tipo de sistema em que o software usado Requisitos funcionais dos usu rios podem ser declara es de alto n vel a respeito do que o sistema deve fazer Requisitos funcionais do sistema devem descrever detalhadamente os servicos do sistema 1 3 Image Repository 1 1 Upload a single image into repository L11 User can select a single image thal is stored somewhere on the user a computer eg CD DVD floppy haad disk memory stick to upload to the reposiiony Li During the selection of an image the aser should have some visual feedback as to what image be is selecting
33. tificar resolver riscos An lise de riscos An lise de riscos An lise de riscos m Prot tipo Prot tipo 3 operacional Prot tipo 2 An lise de riscos Prot tipo 1 Simula es modelos benchmarks Conceito de opera o Requisitos de S W Projeto de produto Projeto detalhado j A de requisitos di desenvolvimento l C digo Teste unit rio Projeto Plano de integra o greg VAV e testes Teste de Planejar pr xima fase integra o cid cd Teste de aceita o i 5 Desenvolver e verificar pr ximo nivel do produto Opera o delagem de Software Prof Fl vio de Oliveira Silva Ph D Setores do modelo espiral Defini o de objetivos Y S o identificados os objetivos espec ficos para cada fase Avalia o e redu o de riscos Y Os riscos s o avaliados e atividades executadas para reduzir os principais riscos Desenvolvimento e valida o 4 v Um modelo de desenvolvimento para o sistema escolhido qualquer um dos modelos gen ricos pode ser Planejamento Y O projeto revisto e a pr xima fase da espiral planejada Prof Fl vio de Oliveira Silva Ph D 29 Rational Unified Process RUP um processo gen rico moderno derivado do trabalho em UML e processos associados Re ne aspectos dos 3 modelos gen ricos discutidos previamente Geralmente descrito por 3 perspectivas v Uma perspectiva din mica que mostra fases no tempo v Uma p
34. tiva aos resultados desenvolvidos incrementalmente e teracao Inter fase v Como mostrado pelo loop no modelo RUP o conjunto todo de fases pode ser executado incrementalmente Prof Fl vio de Oliveira Silva Ph D 32 10 1 2015 Workflows est ticos no RUP Modelagem de neg cios Os processos de neg cio s o modelados por meio de casos de uso de neg cios Requisitos Atores que interagem com o sistema s o identificados e casos de uso s o desenvolvidos para modelar os requisitos do sistema Andlise e projeto Um modelo de projeto criado e documentado com modelos de arquitetura modelos de componentes modelos de objetos e modelos de sequ ncia Implementa o Os componentes do sistema s o implementados e estruturados em subsistemas de implementa o A gera o autom tica de c digo a partir de modelos de projeto ajuda a acelerar esse processo O teste um processo iterativo que feito em conjunto com a implementa o O teste do sistema segue a conclus o da implementa o Prof Fl vio de Oliveira Silva Ph D Workflows est ticos no RUP Implanta o Um release do produto criado distribu do aos usu rios e instalado em seu local de trabalho Gerenciamento de configura o e Esse workflow de apoio gerencia as mudan as do sistema veja o Cap tulo 25 mudan as Gerenciamento de projeto Esse Workflow de apoio gerencia o desenvolvimento do sistema veja os cap tulos 22 e 23 Meio ambiente Esse
35. workflow est relacionado com a disponibiliza o de ferramentas apropriadas para a equipe de desenvolvimento de software Prof Fl vio de Oliveira Silva Ph D 33 10 1 2015 Boas pr ticas do RUP e Desenvolver software iterativamente v Planejar incrementos baseando se nas prioridades do cliente e entregar as de prioridade mais alta primeiro Gerenciar os requisitos Y Documentar explicitamente os requisitos do cliente e manter registros de mudangas desses requisitos Usar arquiteturas baseadas em componentes Y Organizar a arquitetura do sistema como um conjunto de componentes reus veis Modelagem de Software Prof Fl vio de Oliveira Silva Ph D Boas pr ticas do RUP e Modelar o software visualmente Y Use modelos de gr ficos UML para representar vis es din micas e est ticas do software Verificar a qualidade do software v Garanta que o software atenda aos padr es de qualidade organizacional Controlar as mudan as do software Y Gerencie as mudan as no software usando um sistema de gerenciamento de mudan as e ferramentas de gerenciamento de configura o Prof Fl vio de Oliveira Silva Ph D 34 10 1 2015 Scrum noun Yskrami Definition of SCRUM ati 1 aor scrum mage 4 a rugby play in which the forwards of each side come together in a tight formation and struggle to gain possession of the ball using their feet when it is tossed in among them a so the arrangement
Download Pdf Manuals
Related Search