Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>As far as I can see you've got a few glaring gaps in your design, part of the features is implied (linking of categories and pages) and some are left out altogether (login for administrators, user management, preview etc). These are going to make up about half of your small application, and you better include them into the initial outline. Perhaps you may want to take a more systematic approach to designing the CMS. And there are at least three general routes you could take:</p> <ol> <li><p>Design a domain model first, and then design business layer, then UI and data model.</p></li> <li><p>Start with data model and build business layer and UI on top of it. </p></li> <li><p>Model the UI first, then everything else.</p></li> </ol> <p>Regardless of which path you would prefer to take (or combination of) there are some general guidelines:</p> <ol> <li><p>Start with a big picture of work you want to automate. This is called “work scope”. “Big picture” here can be meant quite literally and although it can be a just a story describing the process, it is best to visualise using a rich picture that includes actions, artefacts, other applications, users etc. As for the “big” part of the equation the picture needs to encompass more than the intended product, be bigger than the segment of work you want to automate.</p></li> <li><p>Then outline what specific work you want your product to take care of. This is usually referred to as “product scope”.</p></li> <li><p>Make a list of user roles (or profiles) for your application, list of inputs and outputs, list of external interfaces. </p></li> <li><p>Now you may want to start writing some user stories. You’ll need at least one per user profile, since you need to provide an illustration of all user perspectives.</p></li> <li><p>At this point there going to be just enough information at your disposal to start a more precise modelling of the problem using either domain model, or UI model or data model, whichever you fancy or feel more comfortable with.</p></li> </ol> <p>All of the steps are very much iterative. Once you understand a bit more about the application, its wider context and have a list of features that need to be implemented to meet the requirements you’d be in the position to give some very rough estimates and then go through a prioritisation process. </p> <p>Needless to say that this is just a simplified framework and many software developers would take a different approach to designing an app, depending on their skills, needs, preferences etc. But it could be a good starting point to a more systematic evaluation of the problem you want to solve.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload