Question

I have an application that manage absence of students.

I asked everyone who will use the application (teachers , administration ...) about their needs and feature they want to see in the application.

Now I don't know what steps I should follow before creating the software?

  • should I draw a sequence diagram & use case diagram to explain to my teacher the application's feature & how it work?
  • should I start create a database for the application then begin creating the application? (it will be web with Java EE)
Was it helpful?

Solution

I asked everyone who will use the application (teachers , administration ...) about their needs and feature they want to see in the application.

We call that requirements gathering. It's good but don't be surprised when these change.

should I draw a sequence diagram & use case diagram to explain to my teacher the application's feature & how it work?

We call this design. You can do it this way. Also worth considering is quickly mocking up GUI's with paint programs or paper and pencil. I tend to do this before getting all formal. You can add pictures, scissors and tape. The more you can show people the more they get a feel for the idea and can bring up issues sooner rather than later. Keep doing this until the changes settle down.

should I start create a database for the application then begin creating the application? (it will be web with Java EE)

There are those who let the database be the center of their application. I'm not one of them. I like to keep my business rules and entities at the center. To me the database is just another outside thing I communicate with.

What you need to figure out either way is what your model is going to be. This is how your code reflects what's going on in the real world. With a solid model it's easy to add the rest.

As Laiv rightly points out it's best to do these steps separately. Don't be thinking about how hard it will be to implement when drawing the GUI. Think about what the user needs.

Now just because you do them separately doesn't mean you have to do them days apart. The agile way to work is to push through them all while focused on the smallest thing you can think to delver. Show that to users rapidly and get feedback before you add another feature. Do this and your design won't just be a stab in the dark. You'll be feeling your way to a better design.

Licensed under: CC-BY-SA with attribution
scroll top