1 min de leitura ·

Como funciona um processo de desenvolvimento de software?

Estou em busca de entender o processo para se criar um software, seja um app ou qualquer outro software, como ainda não faço parte do mercado de trablho ainda estou confuso, eu sei que se inicia com a reunião com o cliente entrevistas e levantamento de requisitos, e após isso? essa parte está me levantando duvidas, ainda é utilizados UML? fluxogramas? é feito algum esboço do sitema antes do desenvolvimento?
Me parece que após o manifesto agil e com o uso de desenvolvimento agil nao se usa mais UML ou fluxogramas, qual é o processo então, lembrando apartir do levantamento de requisitos já é feito o desenvolvimento direto sem escopo, é definito apenas a parte e desenvolve ela e depois parte pra proxima? ex: requisito: tela de login. então se faz ela e passa para a proxima num processo de kanban por exemplo.
Mesmo assim me parece viavel algum tipo de fluxograma para se orientar melhor, dai me vem a duvida novamente, pro que não usar? ou por que não se usa? e se isso ainda é usado por favor de algum exemplo ou imagem de algum escopo de projeto.

mayra

2 anos atrás

Olá, akil. Tudo bem?

A UML caiu em desuso nos últimos anos, porém os fluxogramas continuam sendo usados e ajudam a entender o escopo e as regras de negócio de um projeto.

Após o levantamento de requisitos, é comum que sejam elaborados fluxogramas, lista de tarefas, divisão dessas tarefas dentro de sprints (caso o Scrum seja o método adotado). Claro que nem todos os requisitos levantados são necessários, por isso é importantíssimo o papel do Product Owner para priorizar o que é crucial, o "core" da aplicação.

Essas sprints são iterativas até que o projeto seja concluído, sendo submetido a um teste de aceitação, isto é, o cliente deve usar o projeto e sinalizar se aprova o resultado. Antes do teste de aceitação, também devem ocorrer outros contatos do cliente com o produto, para que o processo de desenvolvimento esteja de acordo com as necessidades dele.

As "versões" que são disponibilizadas a cada sprint são incrementais (idealmente). Vamos imaginar que eu tenho um aplicativo de finanças, cujas funcionalidades principais são: adicionar contas a receber, adicionar contas a pagar e visualizar saldo. Eu poderia dividir o desenvolvimento desse projeto (falando bem a grosso modo), em três etapas incrementais: Primeiro a funcionalidade de adicionar contas a receber, segundo a funcionalidade de adicionar contas a pagar e por último o saldo. Desta forma, a cada funcionalidade entregue, é possível testar o projeto e verificar se está ficando de acordo com os requisitos, mesmo que ele não esteja totalmente pronto.

O processo de desenvolvimento é bastante complexo e, em minha humilde experiência, quase todas as vezes, os requisitos e as "tasks" (tarefas atribuídas a cada sprint) mudam com o decorrer do projeto - não por desorganização, mas por amadurecimento dos requisitos e das regras de negócio. Muitas coisas só são identificadas durante o desenvolvimento, por isso, o processo é algo fluído, não é rígido como impunha o modelo cascata.

Eu espero ter te ajudado, qualquer dúvida pode perguntar. Vale ressaltar que essa é a minha visão enquanto desenvolvedora, e um Product Owner ou um Scrum Master devem ter bem mais detalhes a acrescentar.

Abraço!

juliofpsm

2 anos atrás

Cara a melhor a melhor resposta para sua pergunta é "depende", porque varia muito da empresa/projeto/regra de negócio/vontade do desenvolvedor.

Eu trabalho em um ERP e posso dizer que trabalho diferente para cada projeto/cliente.

Um conselho pra você é o livro Domain-Driven Design: Atacando as complexidades no coração do software.

É um pouco denso, mas ele monstra umas histórias sobre levantamento e desenvolvimento de software.

O ideal é você não se preocupar com esse tipo de coisa, porque geralmente o responsavel por essas coisas é o Analista de Sistemas ou o Analista de Requisitos, iniciante que geralmente é programador recebe isso pronto e foca mais no código, mas a título de curiosidade vale a pena.

lucask

2 anos atrás

Cada empresa tem um processo próprio dependendo das necessidades e objetivos que ela tem, isso costuma ser alterado com o tempo.

Podem, sim, ser feitos diagramas, fluxogramas, etc. Tudo isso contribui para a documentação do projeto.

Só é bom cuidar para não criar muitas coisas que não agreguem valor suficiente, por exemplo, se for feita qualquer alteração, será necessário atualizar todos os diagramas relacionados? Isso demanda tempo.

O exemplo mais comum acredito ser o que você comentou, após levantar os requisitos, separar as necessidades do software em diversas tarefas, e então encaminhar cada uma delas para alguém fazer. Isso serve como documentação também, por exemplo, na tarefa “criar uma tela de login” poderiam ser explicados os requisitos dessa tela de login, anexados esboços, diagramas, etc. Quando a tarefa é concluída essas informações ainda poderão ser consultadas no futuro.

Se sua ideia é trabalhar para uma empresa, o esperado é receber um treinamento dos processos utilizados na mesma. Já se for para projetos próprios eu recomendaria fazer o que você acredita que vá facilitar sua vida no futuro, pois com certeza você esquecerá alguma coisa e precisará fuçar para entender novamente. Com o tempo você vai identificando o que ajuda mais.

Da para ter mais noção assistindo alguns vídeos no YouTube com exemplos de gestão de projeto, como o vídeo do Deschamps onde ele utilizou o Github para isso https://youtu.be/tEloMCbLEAE