AP1 MÉTODOS E TÉCNICAS DE ENGENHARIA DE SOFTWARE

Prévia do material em texto

Unigranrio Caxias
Rio de Janeiro, 2023
Proposta do Projeto
Aplicação Prática – AP1
Turma: Métodos e Técnicas de Engenharia de Software
Professor: Gilliard Alves
Nome da Avaliação: Roteiro de Atividades 01
Semestre: 2023/2
Matrícula: 5406196
Aluno: Wallison Silva dos Santos
Contextualização
A importância dos modelos de ciclo de vida ou processos de software é
significativa em termos de organização e sucesso do projeto de software, já que sem
essa definição inicial, dificilmente haverá uma coordenação eficaz da equipe de
desenvolvimento, não será possível precisar quais artefatos deverão ser produzidos,
prazos e orçamentos seriam imprecisos, em resumo, o software dificilmente atenderia os requisitos desejados pelo cliente.
Apesar de existirem diversos modelos de ciclo de vida, como cascata, prototipação, espiral, RUP, e os próprios métodos ágeis, não existe o modelo ideal de software. Cabe aos desenvolvedores escolher aquele que é o mais adequado para cada situação. Algumas empresas, inclusive, utilizam modelos próprios, baseados em boas práticas, ou ainda, versões adaptadas dos modelos já conhecidos. Ou seja, o mais importante é que a construção do software seja organizada e coordenada de maneira que se obtenha no final do projeto, um software de qualidade.
Proposta de Trabalho
Nesta AP1, você deverá responder as questões a seguir:
1) Sabe-se que a metodologia de desenvolvimento de sistemas é um processo que compreende diversas práticas e princípios e possuem os ciclos de vida para definir etapas/passos necessários para realização das atividades envolvidas no projeto. Explique os problemas relacionados ao ciclo de vida de desenvolvimento em cascata, quando aplicado a projetos de médio/grande porte, com inovações tecnológicas ou requisitos instáveis.
Os principais problemas encontrados no modelo cascata são:
· Os projetos de software reais construídos e evoluídos na indústria de software raramente seguem o fluxo sequencial que o modelo prega. Apesar de que esse modelo em forma sequencial possa conter iterações, onde poderíamos passar diversas vezes pelas mesmas atividades, ele o faz indiretamente. Como resultado tem-se que mudanças podem provocar bastante confusão na medida em que a equipe de projeto prossegue.
· É muito raro e difícil para o cliente saber e estabelecer explicitamente todas as suas necessidades. O modelo cascata é muito fortemente baseado nisso e tem dificuldade para adequar a incerteza natural que existem no inicio dos projetos.
· O cliente precisa ter muita paciência, o que raramente acontece. Uma versão operacional (pronta para ser executada no cliente) não estará disponível até estarmos próximo ao final do projeto. Se tivermos um erro grave nas etapas iniciais, como uma especificação mal compreendida e mal especificada, podemos ter um resultado desastroso.
Os problemas surgem quando os projetos são de médio/grande porte e quando há possibilidade de interferência externa pois este modelo funciona de forma linear e sequencial. Só podemos avançar para a próxima etapa quando concluímos as etapas anteriores. Além disso, este modelo dificulta a manutenção do código e os gastos para possíveis atualizações são caros.
2) O levantamento de requisitos é uma etapa crucial para o desenvolvimento de
qualquer sistema. Nesta fase são extraídas informações do cliente sobre o que ele deseja que seja construído. Um levantamento de requisitos mal elaborado
pode acarretar um produto bem distante do que foi solicitado pelo cliente.
Durante esta etapa um dos grandes desafios é a relação do analista de requisitos com o cliente. Essa relação nem sempre ocorre da melhor forma e isto poderá ocasionar ruídos na comunicação e, consequentemente, problemas com o produto final. Baseado no exposto acima, analise o quadrinho a seguir e informe o que ele está representando, e como evitar que situações como esta ocorram?
O levantamento de requisitos bem-sucedido envolve uma comunicação eficaz entre os analistas de requisitos e os clientes. Para evitar situações em que o produto final não atende às expectativas do cliente, considere as seguintes práticas:
1.Compreensão clara dos Requisitos: Certifique-se de que os analistas de requisitos compreendam completamente as necessidades e expectativas do cliente. Isso envolve fazer perguntas claras, utilizar técnicas como entrevistas e workshops e documentar de forma precisa as informações obtidas.
2.Feedback Contínuo: Estabeleça uma comunicação constante com o cliente ao longo do processo de levantamento de requisitos. Isso ajuda a esclarecer dúvidas, validar informações e garantir que a visão do cliente seja incorporada adequadamente.
3.Prototipagem: Desenvolva protótipos ou modelos visuais para fornecer uma representação tangível do sistema proposto. Isso permite que o cliente visualize melhor o produto final e faça ajustes antes do desenvolvimento completo.
4. Documentação detalhada: Registre de maneira abrangente todos os requisitos coletados. Isso inclui especificações claras, casos de uso, diagramas e quaisquer outras informações relevantes. A documentação serve como referência e ajuda a evitar mal-entendidos.
5.Grupo de Trabalho: Garanta que a equipe de análise de requisitos inclua profissionais que possam traduzir as necessidades do cliente para a linguagem técnica e vice-versa. Isso facilita a compreensão mútua e minimiza possíveis lacunas de comunicação.
6. Validação constante: Realize verificações regulares com o cliente para validar se os requisitos coletados até o momento estão alinhados com suas expectativas. Isso ajuda a corrigir possíveis discrepâncias antes que causem problemas no desenvolvimento.
7. Desenvolvimento compartilhado:O desenvolvimento compartilhado, ou Joint Application Design (JAD), é uma técnica que visa criar um ambiente de cooperação no desenvolvimento de sistemas. A ideia é promover dinâmicas em grupo, usando esquemas visuais e reuniões estruturadas. O resultado final do trabalho é documentado e assinado por todos os participantes, criando um vínculo simbólico entre todos.
Esse é o tipo de processo interessante para quem tem clientes de longa data, que gostariam de se envolver mais com a inovação e a criação dos sistemas de gestão. Passar por um processo desse tipo aumenta a confiança e sensação de pertencimento nos clientes, o que é muito útil em tempos de economia digital.
O levantamento de requisitos de software é um procedimento muito importante para o projeto do sistema ERP. Será nessa etapa que as necessidades do usuário serão consideradas em sua totalidade, tornando o desenvolvimento do sistema uma forma de aprimorar a experiência do usuário desde o início. A percepção da qualidade do sistema desenvolvido é muito afetada pelo valor que efetivamente é entregue ao cliente e por isso as reais expectativas do consumidor não podem ser ignoradas.
Ao seguir essas práticas, é possível melhorar a eficácia do levantamento de requisitos e reduzir a probabilidade de que o produto final não atenda às expectativas do cliente.
Parte superior do formulário
Referencias Bibliográficas
https://www.dio.me/articles/modelo-de-desenvolvimento-de-software-em-cascata
https://www.devmedia.com.br/introducao-ao-modelo-cascata/29843#:~:text=Os%20principais%20problemas%20encontrados%20no,sequencial%20que%20o%20modelo%20prega.
https://blog.vinco.com.br/levantamento-de-requisitos-de-software/
https://www.cedrotech.com/blog/levantamento-de-requisitos-e-desenvolvimento-de-softwares/
image1.png