Hierachy Chart On Maintenance Of An Apartment Complex

Hi Nga_5640,

That's a pretty broad question to a detailed application.  What are you trying to do?




Kent

Pencil and paper ;)

If you intend to write software, first write down your requirements, conduct an analysis, design your app, program and test it, and the try to sell it. Just like anybody else. During step 4 (programming) you can tell us your problems with your code. Some of us are quite willing to do more than only coding, so you might get lucky here.

So what's your code by now, and what's the problem with it?

I'm trying to create a hierachy chart of a maintenance tracking application for an apartment complex, using the information below.  Chart should show modules and identify and explain the variables.  Also please indicate if there's any reusable components:
1. Schedule Maintenance On Equipment

2.Print Detailed Instructions On Work Orders to help personnel perform maintenance jobs correctly

3.Use Calendars to Specify Days Off and Work Schedules for Personnel
Balance Workload— it helps identify & fix scheduling problems in maintenance plans

4.Track Parts Used and Inventory Aavailability to reduce out of stock situations
Track Maintenance Costs On Different Equipment & Properties

5. Use History Reports to Review Past Maintenance
Identify Work Ddone as well as Work That Was Missed

Gosh, but it's a major project! I'd say: don't create but buy, in the end a lot better/faster/cheaper. There must be some available on the market, maybe even as Open Source.

I'm a complete novice at programming.  My problem does not involve any specific programming language at this time, only basic concepts and logical approach.  I simply want to know what are my first steps  in designing a hierachy chart of the maintenance of an apartment complex.  What would the design look like using the information I supplied? Do I need more detailed information?  I'm not sure.  I also need to explain my presentation in pseudocode.

Thanks for your answer Master Jef.  Even though you did not provide me with the answer I need, you did give me some insight into the major work programming entails, and I thank you for that. However, I believe you may not have understood me, which is my fault.  I'm not trying to create some software for marketing, all I'm trying to do is to understand basic programming within the scope of logic and design.  I am a newbie I admit-- that I am!  But do you think you could help me in setting up a hierachy chart showing the relationship of my modules, based on the information I provided?  

I was unable to paste the chart.  The arrangement was of this fashion:
Main()
  ScheduleMaintenance()
     PerformMaintenance()
        ReviewMaintenance()
  PrintInstructions()
  SecifyDays Off()
  SpecifyDays Worked()
  ReviewReports()
PrintReport()

Thanks for whatever input.
 

 

 


















































 

 

I never meant to insult you, if I did, my apologies. There's already enough misery in the world.

Pasting a book on application analysis and development would be the best thing to do. When you arranged your code (above), I think you're too far ahead, since writing code is the stage where you have your application already "running in your head". Okay, for a total newbie, here's what you should do for a full-size project for one of your customers:

Step I Requirements
- assume you are the client (and you know nothing about programming or whatsoever)
- write down EVERYTHING you want your application to do (which is more or less what you described in your second post)
- it should be somewhat detailed, but no more than two pages

Step || Analysis
- you will be analysing the application, on an abstract level, without thinking of design and programming
- there are many ways to perform this step, it is different for Proccess Control systems than for Banking systems
- in this case, a data-flow diagramming method might be best applied
- you start with one circle, the Application
- write down all different functions (users/functionaries/roles) using the Application
- write down all the input one function can supply, on a conceptual level (say "schedule data", not "start date")
- if you think you have all proceed to the next level of detail
- write down all processes (small circles) that happen inside the circle (Application)
- write the inputs and outputs
- use datastore symbols to store data temporarily (two horizontal lines)
- let data flow from one circle to the other, or from a store to a process, or from a process to a store
- NB data can never flow from one store to the other without being processed
- continue until you think you have enough detail to go to Step 3

Step 3 Design
- during this step you select the best environment for your application to run on
- depending on the development environment, there are several ways to proceed: old-fashioned design, Prototyping, etc.
- if you're thinking of using C, it's an old-fashioned language requiring an old-fashioned approach
- a database environment might be a lot better, since you have a lot of data that must be stored and worked on

etc.etc.etc.

In this case, you're your own customer, which you might think makes it easier but it is usually harder. Unless you have a lot of experience, you have to be tough on yourself. Write down those requirements! Do the Analysis in full!

Just to help you a little, here's some analysis, translated from the requirements above.

You mention Equipment, that's going to be a data store
You mention Instructions, another store, but related to Equipment
You mention Personnel, a new store, with each a Calender as property
You have a Planning, again a store, related to Equipment and Personnel
You want to track parts, could be part of the Equipment store

Is this something that's more useful to you? I hope I'm making myself a bit clear here. If not, ah, yes, what can I do? I don't know, you cannot learn this from reading an EE question-post written on a Sunday evening by some sod at the other end of the world. I can just tell you that I myself learned to tackle the problems this way, using the Yourdon methodology to visualize it. With a lot of common sense!

And I have the following URL's for you (via Google):
- on DFD's (Data Flow Diagrams): http://www.smartdraw.com/resources/centers/software/dfd.htm
- on ERD's (Entity Relationship Diagrams): http://www.smartdraw.com/resources/centers/software/erd.htm

And thanks for the points!