Blog

SUMÁRIO 1 INTRODUÇÃO 3 2 DESENVOLVIMENTO 4 2. 1 DOCUMENTAÇÃO CASO DE US04 2. 2 TÉCNICA DE MODELAGEM ENTIDADE RELACIONAMENTO 5 2. 2. 1 ENTIDADE E TABELAS 5 2. 2. 2 RELACIONAMENTOS E CARDINALIDADE 5 2. 2. 2. 1 RELACIONAMENTOS 2. 2. 2. 2 CARDINALIDADES 2. 2. 3TlPOS E ATRIBUTOS 6 2. 2. 3. 1 DETERMINANTE 6 2. 2. 3. 2 DERIVADO 2. 2. 3. 3 MULTIVALO 2. 2. 3. 4 COMPOSTO 2. 2. 4ADMINISTRADO 2. 2. 5 MODELO CONC 1 orlo to view nut*ge 2. 2. 6MODELO OGICO DE DADOS 7 2. 2. 7 MODELO Fisco DE DADOS 7 3DESENVOLVIMENTO 8 4MODELOS ÁGEIS E EVOLUCIONARIOS9 4. 1 MODELOS AGEIS9 4. . 1XP9 4. 1. 2 SCRUM9 4. 1. MSF AGI E 10 4. 1. 4A MSF AGILE SOFTWARE DEVELOPMENT 4. 0 10 4. 1. 5 FDD – FEATURE DRIVEN DEVE-LOPMENTIO 4. 2 MODELOS EVOLUCIONARIOS 11 4. 2. 1 ESPIRAL 11 4. 2. 21NCREMENTAL 12 4. 2. 3 DESENVOLVIMENTO BASEADO EM COMPONENTES 12 4. 2. 4SWEBOK12 precisam ser verdadeiras no início do caso de uso, uma pré- condição não atendida impede o uso do caso de uso. Ex: O usuário deverá estar logado no sistema. e) pós-condição; Condições que precisam ser verdadeiras no final do caso de uso, podendo ser outro caso de uso.

Ex: Após o fim do caso de uso, o sistema deverá exibir o aviso “Cadastro efetuado com ucesso”. d) Fluxo de Tarefas; Descreve a sequência em que as ações devem ser executadas, podendo haver fluxo de tarefa principal, alternativo e exceçao. – O usuário clica no botão “Novo Cadastro”. 2 – O sistema mostra a ficha de cadastro. 3- O usuário preenche com os dados. 4- O usuário clica no botão “Cadastrar”. 5 O caso de uso é finalizado. 6 – A mensagem “Cadastro efetuado com sucesso” é exibida. TÉCNICA DE MODELAGEM ENTIDADE RELACIONAMENTO 1 ENTIDADE E TABELAS A entidade é um objeto básico, que pode ser de existência fisica como eu ou um conceito como este trabalho, cada entidade em seu atributo, que são propriedade que cada entidade tem que a difere uma da outra, exem lo uma entidade carro tem seus atributos placa, cor, chassi e capacidade de PAGF 10 mundo real, cliente compra produto, onde o verbo conjugado indica o relacionamento exemplo: pessoa se relaciona com produto. 2 CARDINALIDADE Cardinalidade é a quantidade de eventos que as entidades podem estar associadas a uma ocorrência de entidades que se quer avaliar.

Cardinalidade é a “regra de negócio” entre as entidades envolvidas no relacionamento. Exemplo: uma pessoa pode comprar vános produtos (1 ,n), só que por xemplo uma caixa e sabão em pó só pode ser vendida para uma pessoa (1,1) mas varias caixas de sabão em pó podem ser vendias para varias pessoas (n,n). 3 TIPOS E ATRIBUTOS 1 DETERMINANTE É o atributo que separa e diferencia uma ocorrência de outra ocorrência da entidade. 2 DERIVADO É um atributo que o valor é derivado do valor de outro atributo. 3 MULTIVALORAVEL 10 modelo físico de dados. MODELO LOGICO DE DADOS O Modelo lógico de dados representa a estrutura de um banco de dados, ele já contem as entidades e seus atributos sem levar em consideração nenhuma especificação de um SGDB( Data Base Magenament na sigla em inglês). 7 MODELO Físico DE DADOS O Modelo físico de dados por outro lado representa as características do armazenamento físico dos dados ou seja se preocupando com as especificações do SGBD. DESENVOLVIMENTO flexibilidade para acompanhar as mudanças. O resultado do processo deve ser um software que é realmente útil para o cliente.

A metodologia é baseada em princípios semelhantes aos da XP: equipes pequenas, requisitos pouco estáveis ou desconhecidos e iterações curtas para promover visibilidade para o desenvolvimento. No entanto, as dimensões em SCRIJM diferem de XP. A SCRIJM divide o desenvolvimento em iterações (sprints) de trinta dias. Equipes pequenas, de até dez pessoas, são formadas por projetistas, programadores, engenheiros e gerentes de qualidade. Estas equipes trabalham em cima de funcionalidades (requisitos) definidas no inicio de cada spnnt. A equipe é responsável pelo desenvolvimento desta funcionalidade.

Na SCRIJM existem reuniões de acompanhamento diárias. Nessas reuniões, que são preferencialmente de curta duração (aproximadamente quinze minutos), são discutidos pontos como o que foi feito desde a última reunião e o que precisa ser feito até a próxima. As dificuldades encontradas e os fatores de impedimento (bottlenecks) são identificados e resolvidos. 3 MSF AGILE A Microsoft Solutions Framework surgiu em 1994 como um conjunto de boas práticas compiladas pela Microsoft a partir de sua experiência na produção de sofMare e em serviços de consultoria.

Desde então, o MSF evoluiu, tornando-se um framework flexível para nortear o desenvolvimento de projetos de software. Essa evolução também teve o intuito de acompanhar tendências bem sucedidas no meio da engenharia de software, como a capacidade de responder à necessidade de mudanças rapidamente. O MSF 4. 0 será nosso objeto de estudo e suas principais característi liadas. estudo e suas principais características serão avaliadas. 4 A MSF AGILE SOFW,/ARE DEVELOPMENT 4. Por mais semelhanças que um projeto possa ter em relação a outros, cada projeto de software é único, devido a uma série de fatores que incluem desde o tipo de aplicação a ser construída, necessidades especificas de cada cliente e até restrições de cronograma e recursos. Já existe desde o MSF 3. 0, a consciência por parte de seus criadores de que é impossível definir um único processo de desenvolvimento de software que eja adaptável a qualquer situação. Foi devido a isso que oMSF 4. 0 fol lançado em duas versões dlferentes, uma que aborda processos ágeis e outra que aborda processos tradicionais.

O MSF 4. 0 sustenta os seguintes 5 FDD – FEATURE DRIVEN DEVELOPMENT Entre as outras abordagens de programação ágeis a FDD situa- se numa posição intermediária. Oferece um conjunto coerente de princípios para desenvolvimento de projetos e Engenharia de Software, mas também coexiste com abordagens mais especialistas. 2 MODELOS EVOLUCIONARIOS 1 ESPIRAL Este modelo foi desenvolvido para abranger as melhores aracterísticas tanto do ciclo de vida clássico como da prototipação, acrescentando ao mesmo tempo, um novo elemento’, a análise de ris esses paradigmas.

O “nível seguinte”. 4. Atualização feita pelo cliente: avaliação dos resultados da engenharia. Ele usa uma abordagem “evolucionária” à engenharia de software, capacitando o desenvolvedor e o cliente a entender e reagir aos riscos em cada fase evolutiva. O modelo espiral usa a prototipaçào como um mecanismo de redução de riscos, mas, o que é mais importante, possibilita que o desenvolvedor aplique a abordagem de prototipação em qualquer etapa da evolução do roduto.

Ele mantém a abordagem de passos sistemáticos sugerida pelo ciclo de vida clássico, mas incorpora-a numa estrutura iterativa que reflete mais realisticamente o mundo real. O modelo espiral exige uma consideração direta dos riscos técnicos em todas as etapas do projeto e, se adequadamente aplicado, deve reduzir os riscos antes que eles se tornem problemáticos. O modelo de ciclo de vida espiral apresentado por Boehm em 1988 combina ascaracterísticas positivas da gerência (documento associado às fases do CICIO) do modelo de cascata com as fases sobrepostas encontradas no modelo incremental e, também. m as versões anteriores de um sistema do modelo de prototipação. O modelo em espiral parte do princípio de que a forma do desenvolvimento de software não pode ser completamente determinada de antemão. A prototipação é vista como um meio de redução de riscos, a permitir que se descubram os problemas potenciais antes de se comprometer com um sistema completo. O modelo caracteriza- se como um gerador de modelo de processo.

Cada ciclo do modelo em espiral possui quatro atividades principais: elaborar objetivos, restrições e alternativas para entidades de software, valiar alternativas com rela ão aos obetivos e restrições, e ide para entidades de software, avaliar alternativas com relação aos objetivos e restrições, e identificar as principais fontes de riscos. 2 INCREMENTAL Combina elementos do modelo cascata sendo aplicado de maneira interativa. O modelo de processo incremental é interativo igual à prototipagem, mais diferente a prototipagem o incremental tem como objetivo apresentar um produto operacional a cada incremento realizado.

Esse modelo é muito útil quando a empresa não possui mão de obra disponível no momento para uma implementação completa, dentro do prazo stipulado. 3 DESENVOLVIMENTO BASEADO EM COMPONENTES Desenvolvimento baseado em componentes ou component- baseddevelopment (CBD) também é conhecido como component-based software engineering (CBSE) ou simplesmente componente de software, não define o que é um componente e restringe-se a dizer que o modelo de desenvolvimento baseado em componentes utiliza paradigma de orientação a objetos baseando-se em uma classe como código reutilizável, ou seja, o componente.

Em orientação a objetos uma classe encapsula dados e algoritmos e este último também pode ser usado para manipular os dados. Caracteriza-se esse modelo como incorporador do modelo espral com uma abordagem Iterativa para a criação de software.

Através desta abordagem uma biblioteca de classes é construída com as classes identificadas no desenvolvimento do software e a partir de então toda iteração da espiral deverá verificar o conteúdo da biblioteca que ode ser reutilizado ou identificar se novas classes devem ser blioteca para posterior Engenharia de software possui vasto material e várias técnicas para sucesso de softv,’are, então o IEEE montou um comitê que se reuniram e montaram um guia chamado SWEBOK ue desmembra a engenharia de software em dez áreas de conhecimento que são: • Requisitos de Software, • Projeto (Design) de Software • Construção de Software • Teste de Software • Manutenção de software • Gerência de Configuração de Softw’are • Gerência de Engenharia de Software • Processos de Engenharia de Software • Ferramentas e Métodos de Engenharia de Software • Qualidade de Software Cada uma das áreas de conhecimento é decomposta em itens, que são os assuntos de conhecimentos a serem considerados pelo projeto.

Conforme o projeto deixa claro, os engenheiros de oftware não devem receber somente os conhecimentos estabelecidos pelas respectivas áreas, mas também outros conhecimentos dos cursos com os quais a Engenharia de Software se relaciona. Foi montado sobre três versões onde a ultima definiu-se como final. São elas: • Homem de palha • Gerenciamento; • Matemática; • Gerência de projetos; • Gerenciamento da qualidade; • Ergonomia de software; • Engenharia de sistemas. Mesmo com algumas limitações o SWEBOK é um ótimo guia que apóia o desenvolvimento de software, e que pode ser usado como um diferencial e apoio nesse desenvolvimento