Solved

Formulating DFD's and ERD's in the design phase of a new system

Posted on 2004-10-07
4
482 Views
Last Modified: 2010-08-05

I am currently in a group who is working on a new automated system for a business.  This system will be used for employee shift changes and keep track of these shift changes.  We have formulated the Context Diagram which contains an Employee and Manager entity, and breaks off into one process which is the Shift Change System.  From there we go to the Level 1 Diagram, which again contains an Employee and a Manager entity.  The processes now, in the level one diagram are stumping all of us.  We are confused as to where to go from here, and what should be put in the processes, and what data flow information should go where, and then after the DFD's, how exactly are the ERD's going to be drawn?...Thanks to any and all for any help you can provide.  I really appreciate it.  
0
Comment
Question by:wescs
  • 2
4 Comments
 
LVL 9

Accepted Solution

by:
solution46 earned 500 total points
ID: 12257089
wescs,

first off, it is essential that you get this bit right if the application is going to have any use and longevity. If you're not sure how best to go forward, have you considered taking an application architect to help you through this stage? Contract architects don't come cheap but you should only need one for a few weeks to help get your design sorted, good ones will have experience of problems similar to the ones you're experiencing for the first time and they will potentially save you a fortune in future re-designs.

Having said that, if a temporary architect is out of the question for budget or other reasons, these are the processes I would normally go through in the initial design of a new system.

1. Build up a FULL user specification. It may appear trivial at first but you'll be surprised how often users are expecting certain functionality to be in place 'because it was like that in the last one we had'. As often as not, thy will assume this stuff will always be there and only tell you about new things unless you prompt them. When gathering your specs, try to categorise the requirements according to a) essential to get the job done, b) nice to haves / help get the job done more easily c) future things we need to consider (with timeframes where relevant). At this stage, you should still be looking at a broad range of requirements. You probably wont implement a large number of them, but you need to be aware of them so that you don't design them out of your system by mistake.

2. Build up your Use Case Requirements. These are based on the specification, but group requirements together. I prefer to build basic functionality flow charts at this point to get an overall idea of what the system needs to do, what type of user needs to be able to do what, etc. In short, this is the initial system design.

3. Go back to your users with the UCRs. By explaining the proposed processes to them, they will be able to identify any areas that are missing or incorrect.

4. Estimate time taken to complete each of the UCRs. Estimate your figure high, then double it to get a realistc idea of how long it will take to write! I would suggest a phased approach with critical functionality appearing in early releases and more functionality being added in later releases. Go back to your

5. Go back to your users and project owner with your requirements. Go through each of the UCRs and explain the processes in each to your users. This should highlight any areas that are missing or incorrect. Your time estimates will help your users assign priorities and get past the 'everything is P1' attitude.

6. Get the project owner to sign off your UCRs. They will form the basis of your 'contract' with them and give you some come-back if the requirements change half way through.



You are now ready to start designing the system itself. I prefer to start off with the object model.
1. Take a flipchart pad. Go through each of your UCRs and identify every 'real world' entity within them (e.g. Customer, Team, Product, Address, etc.). Give one sheet from your flipchart pad the name of each of these identites and pin them to a wall.

2. Now go back through the UCRs and identify each a) responsibility, b) key piece of information for each entity. Write these on the flipchart sheets pinned to your walls. e.g. for 'Customer', likely responsibilities are 'can make purchase', 'can change address' and likely key bits of information are 'name', 'addresses', 'existing reference number'. At this point, include all responsibilities regardless of priority (but mark them with the appropritate priority) but you only need to worry about the key properties. This will give you an idea of what you need to consider while designing your system.

3. You can now draw your initial object model for each release phase. This is effectively the Context Model you mentioned. In most cases, the entities on the flipchart sheets will map roughly to a distinct object but you should be able to see where you need extra objects or can combine entities into one object. For instance, Customer and Supplier will have a lot in common. In this case, you will probably find that an 'Organisation' object will handle all the common functionality (address handling and so on). This will allow smaller Customer and Supplier objects that inherit the Organisation object and add their own functionality. For each model, only include the responsibilities you need for that phase, but you may as well include all properties. Each responsibilty from the flipchart pages will become a method in the Object Model; each piece of information will become property. This stage requires rtechnical experience and I would strongly recommend hiring if you do not have the skills in house.

4. Go over the object model and work out the most efficient way of storing this information on a database. Again, in most cases one object will map roughly to one table but you may choose to add extra tables to make things easier in some cases. This is the beginning of your ERD diagram.

5. Go through the Object Model and ERD, checking that the functionality and data stored is sufficient to meet each of the necessary UCRs. Repeat stages 3 and 4, adding detail and makeing changes in each iteration, until you are happy that all UCRs can be met.

6. When you are happy with your Object Model and ERD, go over tham one more time and re-estimate time to complete each phase. You now have far more detail to work with and should be able to give a more accurate estimate. If the new estimate is over your original one, go back to the project owners and work out whether to revise the deadline or remove functionality from each release. When both you and the owners are happy, get project sign-off. You are now committed to completing on time!



Providing the above has been followed sufficiently well (let's face it, you can probably cut out or combine a lot of it together unless you have a very big project), the development stage should be relatively straight-forward: you know exactly what you are designing and already have a plan of how it will work. One last thing I would suggest is building a test frame for each of the proposed objects. This should provide all expected inputs (including ones the users aren't supposed to give it!) and provide the expected outputs (including error messages where appropriate). This will allow you to distribute development among a team of developers as you only need a set of completed objects and no longer care about the inner workings. It will also make testing future releases easier as you know that if each object reponds as expected, the application will perform properly.


Hope this helps,

s46.
0
 
LVL 9

Expert Comment

by:solution46
ID: 12257216
er, a couple of amendments to the above...


In the first section, ignore point 3 as it is covered by point 5.
Also, point 6 will only give you a preliminary agreement. In large scale systems, this will be used to judge whether to invest in detailed planning or not. The real 'contract' wont come until point 6 in the second section.

s46.
0

Featured Post

Why You Should Analyze Threat Actor TTPs

After years of analyzing threat actor behavior, it’s become clear that at any given time there are specific tactics, techniques, and procedures (TTPs) that are particularly prevalent. By analyzing and understanding these TTPs, you can dramatically enhance your security program.

Join & Write a Comment

Suggested Solutions

Title # Comments Views Activity
PDO and Database 1 88
Wordpress data download 4 73
xBase++ 6 69
Linking dictionary and columns together 2 50
Creating and Managing Databases with phpMyAdmin in cPanel.
Read about achieving the basic levels of HRIS security in the workplace.
Video by: Steve
Using examples as well as descriptions, step through each of the common simple join types, explaining differences in syntax, differences in expected outputs and showing how the queries run along with the actual outputs based upon a simple set of dem…
Polish reports in Access so they look terrific. Take yourself to another level. Equations, Back Color, Alternate Back Color. Write easy VBA Code. Tighten space to use less pages. Launch report from a menu, considering criteria only when it is filled…

747 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

12 Experts available now in Live!

Get 1:1 Help Now