CAPTULO 1 - INTRODUO Sistemas de software so abstratos e intangveis, no h limites para o potencial do sof tware.

No entanto, por causa da falta de limites fsicos, sistemas de software pod em rapidamente se tornar extremamente complexo, difcil de entender, e expendicios o de mudar. As principais caractersticas de um software so: Mantenabilidade Segurana Eficincia Usabilidade Engenharia de software importante por dois motivos: 1 - Mais e mais, indivduos e sociedade dependem de avanados sistemas de software. Ne precisamos estar aptos a produzir sistemas confiveis e fidedignos de maneira ec onmica e rpida. 2 - mais econmico, falando a longo prazo, usar mtodos de engenharia de software no desenvolvimento de software do que escrever programas de maneira pessoal. Na ma ioria dos sistemas, a maior parte dos custos so os que envolve a mudana no cdigo de pois que ele foi colocado pra uso, ou seja, na manuteno. As quatro principais etapas no processo de software que resultam no produto fina l so: Especificao de software Desenvolvimento de software Validao de software Evoluo do software Apesar de no haver um mtodo que se aplique igualmente a todos os tipos de software s, h constantemente 3 problemas que afetam a maioria deles: Heterogeneidade dos sistemas: o cross plataforma Mudana nos negcios e no social: essas mudanas aocntecem rapidamente, e o software p recisa acompanhar e se adaptar, as tcnicas precisam mudar, as ferramentas tambm pr ecisam mudar Segurana e confiana: preciso que o software no vaze informao Alguns fundamentos que servem de base para todos os sistemas de software: 1 - Devem ser desenvolvidos utilizando um processo de desenvolvimento organizado e compreensivo. A organizao que desenvolve o software deve planeja o processo de desenvolvimento e ter a idia clara do que vai ser produzido e quano vai ser compl etado. Diferentes processos so usados para diferentes tipos de software. 2 - Segurana e performance sso importantes para todo tipo de software. Um sistema deve funcionar confrome o esperado e estar sempre disponvel ao usurio, deve ser se guro contra ataques externos e deve ser eficiente na maneira como performa sem g astar rercursos desnecessariamente. 3 - importante gerenciar e compreender os requisitos e as especificaes de software . Deve saber o que o que diferentes clientes e usurio esperam do sistema e deve s aber controlar as expectativas para que um software til possa ser entregue dentro do prazo e do oramento. 4 - Deve-se fazer uso eficaz de recursos j disponveis. Quando apropiado reutilizar software que j foi desenvolvido em vez de fazer um novo.

CAPTULO 2 - PROCESSOS DE SOFTWARE O problema no desenvolvimento incremetnal que o processo no visvel, como o desenv olvimento feito rapidamente nem sempre gerado documentao do que est sendo feito, as sim fica difcil de avaliar o progresso do software pelos gerentes. A estrutura do sistema tende a se degradar, como est sempre mudando com novos requisitos sendo adicionados, requer uma constante refatoramento do cdigo para melhora-lo. Ele ten de a ficar complicado para sistemas grandes, complexos e que se extendem por um longo prazo e quando vrias equipes trabalham no sistema.

CAPTULO 3 - DESENVOLVIMENTO GIL Caractersticas fundamentais

1. O processo de especificao, design e implementao so intercalados, no h requisitos es ecficos, os requisitos de usurio apenas definem as caractersticas mais importantes do sistema, a documentao gerada pelas plataformas de desenvolvimento

2. O sistema desenvolvido em uma sria de verses. O usu+ario final e stackeholders esto sempre envolvidos na especificao e na validao de cada verso, novas mudanas so se e feitas no cdigo e implementadas para a prxima verso. 3. Interfaces de usurio so desenvolvidas utilizando ferramentas interativas que pe rmita rpidas modificaes. MANIFESTO Estamos descobrindo novos modos de desenvolver software ajudando e os outros a f azer. Indivduos e interaes acima de processos e ferramentas. Software funcional em vez de documentao compreensiva. Colaborao do cliente em vez de negociao do contrato. Responder a mudanas em vez de seguir um plano Desenvolvimento gil til quando se desenvolvie software para empresa pequana ou de mdio tamanho CAPTULO 4 - ENGENHARIA DE REQUISITOS Requisitos de usurio, so declaraes em linguagem natural juntamente com diagramas e f iguras, de quais servios espera-se que o sistema proporcione parao usurio e sobre quais restries eles devem operar. Requisitos do sistema so descries mais detalhadas das funes, servioes, e restries de raes do sistema. requisitos de produtos, requisitos organizacional, requisitos externos CAPTULO 5 - MODELAGEM DE SISTEMAS Modelagem de caso de uso vastamente utilizado para ajudar na elicitao dos requisit os. Cada caso de uso representa um processo discreto que envolve uma interao exter

na com o sistema. Diagramas de sequncia no UML so usados primeiramente para modelar interaes entre ato res e objetos em um sistema e a interaes entre os prprios objetos. Representa um ca so de uso de modo mais detalhado, mostrando a interao dos objetos envolvidos. Modelos estruturais de software mostram a organizao do sistema em termos de compon entes que compe o sistema e suas relaes. Diagramas de classe so usados quando se segue um desenvolvimento orientado a obje tos para mostrar as classes dos sistema e aa associao entre essas classes. Usa-se um diamante para representar a associao do tipo agragao, um objeto composto p or outros objetos. CAPTULO 6 - PROJETO DE ARQUITETURA Existem trs vantagens em ter um desing de arquitetura 1 - A arquitetura uma apresentao de alto nvel que pode ser usada como foco na discu sso com os stakeholders 2 - Na nalise do sistema, como ver os pontos crticos dos requisitos, como performa nce, confiana e mantenabilidade 3 - No reuso em larga escala, outros sistemas podem fazer uso do mesmo sistema a rquitetural Projeto de arquitetura um processo criativo onde projetao a organizao do sistema q ue satisfaa os requisitos funcionais e no funcionais do sistema. mvc model view controller por camadas CAPTULO 7 - DESENVOLVIMENTO E IMPLEMENTAO Para identificar as classes em um sistema orientado a objetos: 1 - Utilizar anlise gramatical da lingua natural da descrio do sistema, objetos e a tributos so substantivos, operaes e servios so verbos 2 - Utilizar entidades tangveis (coisas), usar domnios, papis, eventos como pedidos , inter~es como reunies, localizao como escritrio 3 - Utilizar uma anlise baseada em cenrio, analizando e identificando objetos, atr ibutos e operaes. gerenciamento de configurao o processo de gerenciar as mudanas feitas no sistema. gerenciamento de verso - manter o controle das verses integrao do sistema - que verses do componente so utilizados para criar cada verso rastrear problemas CAPTULO 8 - TESTE DE SOFTWARE O processo de teste tem dois objetivos 1 - Demonstrar ao desenvolvedor e o cliente que o software cumpre os requisitos. Para um software customizado deve ter pelo menos um test para cada requisito do documento de requisitos. Para software genrico, deveria ter testes para todos re cursos do sistema, e as combinaes entre os recursos tambm.

2 - Para descobrir sistuaes em que o comportamento do sistema no o esperado ou no de acordo com as especificaes. Consequncia de defeitos de software. Avaliam-se travam enteos, quebras, interaes entre sistemas no desejadas, corrupo de dados, computaes inc rretas. Validation: Are we building the right product? Verification: Are we building the product right? O objetivo da verificao checar se o software atende aos requisitos funcionais e no funcionais. Validao um processo mais genrico. garantir que o software atende as expectativas do cliente. Validao importante pois nem sempre os requisitos so claros, eto importante saber se o software est e acordo com o cliente desejava, que o sosftware est bom o suficiente para ser usado como era esperado. Testes podem ser automatizados, mas a criao deles no automtica. Tipicamente h trs estgios de teste: 1 - Teste durante o desenvolvimento, geralmente pelos proprios programadores 2 - Teste de release, com um time s para teste, testando uma verso final do softwa re antes desse ir para o cliente, e ver se atende os requisitos do sistema. 3 - Testes com usurio, usurios em potenciais utilizam o sftware em seu prprio ambie nte. Teste de aceitao, um dos testes feitos pelo usurio. Diz se o software est pron to ou precisa de mais desenvolvimento. Debugging consertar error e problemas resultantes de um teste. 1 - Teste unitrio - testa os objeots das classes, suas funcionalidade ou mtodos. 2 - Teste de componentes - vrios units 3 - Teste do sistema Possveis erros ed interface, paramnetros, memoria compartilhada, procedimento de interface, always test the interface with null pointer parameters. Use stress te sting Teste de sistema, diferentes componentes so colocados juntos, diferentes componen tes feitos por inmeras equipes so integrados. TDD faz parte da metodologia gil, ele incremental, desenvolve o teste e codifica, no codifica de novo at ter passado no teste. Todos os testes feitos anteriormente so feitos nos novos testes. TDD proporciona ao programador um melhor entendiment o do cdigo, para fazer o teste preceisa saber o que est testando, assim a codificao fica mais fcil de ser feita. Vantagens do TDD 1 - Cobertura do cdigo - todo o cdigo est coberto por teste, cdigo testado assim que feito, defeitos so descobertos desde o inicio do processo de desenvolvimento. 2 - Teste de regresso - os testes so incrementais, sempre que um novo teste adicio nado, os anteriores tambm so cehcados. 3 - Simplifica o debug - quando ocorre algum problema esse precisa ser debugado,

e o teste indica onde foi ocorrido o erro. 4 - Documentao do sistema - os testes servem como uma forma de documentar o andame nto do software. Reduo de custos. Pode ser ruim em abientes multi-thread, se estiver utilizando componentes e reus ando software precisa fazer teste para eles tambm. CAPTULO 9 - EVOLUO DE SOFTWARE A maior parte dos custos de um software est na evoluo, na manuteno Conforme o softwaer modificado, sua estrutura tende a se degradar e as mudanas se tornam cada vez mais dispendiosas. Geralmente acontece quando o sistema operaci onal muda ou o hardware muda. Manuteno no cdigo 1 - Reparar erros. 2 - Adaptar o sistema para um novo OS ou harware. 3 - Adicionar funcionalidades. Legacy systems are old systems that are still useful and are sometimes critical to business operation Dificuldades para aplicar modificaes depois do cdigo pronto: Falta de estabilidade no time Falta de pratica Habilidades do time - ter que aprender novas linguagens Idade do programa e sua estrutura Itens a se verificar na manuteno. Idade, perfrmance, taxa e erros, custo de manuteno, interoperabilidade, estabilida de do suporte.