Is it a good choice to start a project with Diagram use cases, then class diagram?

Asked

Viewed 92 times

0

I have an idea of software, but I don’t know if I should go directly to the class diagram and then the coding or if first of all I should use a use case diagram. I will work on this software alone. It is a long-term dream that I will do in my spare time, no hurry! Work with . NET c# MVC.

c# asp.net-mvc classes diagram use-cases

  • Hello!! I work with web programming in php, I always make a use case diagram , as it gives me a better basis than I should do and which points are most important for the system to work. But when it comes to an individual project this method becomes somewhat personal, finally, I hope to have helped friend!

1 answer

1

That answer is based entirely on my opinion.

Diagrams is a management mode/specification/documentation old school.

Search to document your requests via User Stories. Are simpler to create, and after interpreting to develop.

Example of a User Story:

HOW a visitor to the site

WHEN I am on the homepage

And click on the link "Register"

THEN a registration form must open.

Form details: full name, email and password.

Each user story has a type. Ex:

  • Feature: New functionality or change;
  • Bug: Correction of something implemented;
  • Epic: Requires others user Stories are created to fulfill that desire.
  • Tech: Changes proposed by developers that do not affect the business. How to update Nuget Packages, create tracking for Application Insights, etc.

Have phases:

  • Icebox: They were created only to be analyzed in the future - which may be soon, in years, or even never. The idea is to never stop writing an idea and lose something..
  • Backlog: The story will be implemented and is in line to be developed
  • Finished: The story has been developed or aborted.

Important: These phases do not necessarily reflect the phases of a software development. They often do, but this is not the case with my example. It is common to see phases such as "Started", "Finished", "In tests", "Approved for production", etc.

And have "Complexity Points" or "Effort Points". This should follow the Sequence of Fibonacci:

  • 1 pt: Just typing correction, text change. Does not involve code change.
  • 2 pts: Small code or screen changes. Nothing that changes business rules, criticality or specific tests.
  • 3 pts: Regular effort like creating a new simple Feature, screens, etc. It is the most common.
  • 5 pts: Great effort, will touch various points of the system, change large business rules, affect testing or integration with other systems.
  • 8 pts: Epico. This story must be broken into other simpler stories.

One can go further. There are strategies that go beyond the 21 pts. I do not recommend, it gets vague and difficult to understand what is 5pts and what is 8pts. But it goes from your strategy and how your team feels comfortable.

These points have no relation to "hours of development" - which to me is also "old school", an obsolete way of managing project demand. Think about it this way: What is the complexity of sweeping a floor? It’s very low, sweeping is simple. And what changes from sweeping a bathroom rug to a parking lot? The complexity is the same.

There are several systems to help you manage these stories.

PS: I believe your question will be closed because it is opinion.

  • @Ivan, the answer didn’t answer you?

Browser other questions tagged c# asp.net-mvc classes diagram use-cases

You are not signed in. Login or sign up in order to post.