Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Today’s lecture will discuss Database Plannings, some guidelines on how to select a DBMS, selec CASE (Computer Assisted Software Engineering) and Fact Finding in order to do a good Conceptual Design
  • Database planning should include Conceptual, Logical and Physical Design. Conceptual design is the data as seen by end-user. Logical design is the data associated with the Model (Relational Model in most cases), but still independent of hardware and software. Physical design is how data will be stored on a specific hardware/software plantorm.
  • In the conceptual design, you should try to identify the user view for each individual or group of users.
  • To obtain the user requirements and consequently the conceptual design, one can do each individual user or role needs and then integrate that to get the full conceptual view of the system.
  • Ideally, the DBMS should be chosen at the Conceptual Design stage. The figure above is a good checklist of possible requirements that a Database needs. Note that not all databases will need all the requirements. However, it is nice to have a checklist like the one above available.
  • These are some very important questions that one should answer or estimate when purchasing a DBMS. Volume estimates : a prediction of the resources that will be required. Data Usage . Aproximately how many orders will be done during one month ? Will data only be retrieved (really on) or will it be updated ? Will data be updated. If it is only retrieved and only one or a few users, one may consider a personal DBMS.
  • Below is a weighted factor scoring model. One practical way to select between products (Databases, IP providers, Networks, etc). Each feature is given a Rating (how good it ranks compared to similar items) and a Weight (how important is this feature). The score of each feature is represented by the product of RATING and WEIGHT. The best product will be the one who has the createst final score (sum of all scores). What happens if the product you think is best doesn’t win ? You should not forge the data or simply go with the results that you are not comfortable. You should also not just declare the other project has the winner. You should probably try to analyze each individual item and evaluate to see that they were given the proper rating and weight.
  • Above are two links above are articles on how to select a specific DBMS. One should consider if they need an Enterprise DBMS where data is stored for the whole organization, a Departmental DBMS, where it is shared by a specific department or group, a personal DBMS that is used by one person, or a Mobile/embedded DBMS that can be used on a PDA or embedded device.
  • CASE tools are something that we may use in any of the phases (conceptual, logical, physical) of developing your database. An simple example of CASE tools is when you use Microsoft access and create a query with the wizard or the designer and view the query in SQL. If you don’t know how to do this, please contact me. Other things that case tools can do is to help you create an ER diagram and then automatically convert your ER diagram to tables for a specific DBMS.
  • This diagram shows that there are Upper Case tools (tools that help with Conceptual Design, Logical Design) or LowerCase tools (tools that help with Physical Design or Implementation) as well as Integrated-Case (tools that help with the whole life-cycle of developing a Database. A main problem commonly found in CASE tools is that they are not integrated. They are just for a specific part of the design phase.
  • As shown below, the CASE tools speed up the process and guarantee a certain consistency. However, besides the Lack of integration between high end (upper case) and low end (lower case) that we discussed in the last slide, CASE tools are often good for creating, but not always as good for modifying. For example, MS-Word can create a web-page very fast with a simple Save AS, but it gives you less flexibility to edit and Notepad (manually) may work better for modifying web-pages. I once used a Case tool called Jennifer that automatically generated Database Applications for DBASE II and FOXBASE. We were developing software in the headquarters of a company that had branches throughout Brazil. The CASE tool really speeded up our process. However, when we tested in the branches, we found out that the CASE tool had generated very inefficient code (the computers at the branches were very slow. Another problem of CASE tools is that they tend to generates Silver bullet syndrome. Silver bullet syndrome is when the developers find a new tool or solution and thinks that it will solve all their problems. They believe that the tool will do magic. The problem with this is that they then provide management with an unrealistic schedule. Studies have shown that CASE tools frequently give you an illusion that they will accelerate the software development process significantly (such as four or five times faster) and they usually only accelerate about 20% even if we use the correct case tools. I am going to try to illustrate with the next slide.
  • The Categories form below Creates, Reads, Updates and Deletes rows in the Categories table. Likewise, the Customers, Employees, Suppliers and Products table do the same. Using MS-Access’s Form Wizard to create forms, you can create these forms very fast. Perhaps 5 or 10 times faster than you can do it with Java or C++, for example. However, a CASE will not help much with the ORDERS form. It cannot automatically generate a form that performs ad-hoc operations/more complicated operations. And in a software/database development project, it is the hard tasks that take up the most time and really delay a project.
  • A CASE tool is great for creating a Prototype or a working module. Not that great to create the final version.
  • Next we will analyze Fact Finding. When creating a Database or Developing a New software the first phase (even before Conceptual or Logical Design) is to do fact finding (or also called requirements analysis). There are many different techniques to find out what the user needs: interviews, questionnaires, document gathering, etc. We will discuss them in the next slides.
  • Although companies usually use a combination of two or more methods from the list above, interviewing is the most popular.
  • Documents refer to gathering existing forms, reports and other documents that the company currently uses to operate the business that we are trying to automate. These documents may be manually generated or from an existing Information Systems that we are trying to improve. The idea behind Documents is that by knowing the Input and the Output, one can figure out the process.
  • Interviews, like I said in a previous slide, is the most popular. It is very flexible and enables the interviewer to adapt as needed. The face-to-face provides insights that otherwise it wouldn’t be possible. The interviewer can alter the nature of the interview as they feel necessary.
  • Here is a summary of the adv/disadv. of interview. Of course, the success of the interview also depends on how prepared the interviewer is.
  • It is important that we know who to interview. Frequently, to satisfy both technical and political problems, we need to interview the person who is formally in charge as well as the person who really knows/does the work. In designing interview questions it is important that we find the right balance between open ended such as “What do you think needs improvement in the current system” and closed ended questions such as “Is the maximum discount that a customer can have 5 or 10% ? In the next slides we will also look at Preparing, Conducting and Post-Interview
  • Before going to interview a client, the interviewer should develop a list of questions as well as follow-up questions for antecipated answers. Such as, if the user responds with X to question Y, I will follow up with question Z . It is important that the inteviewee is informed why they are being interviewed as well as the areas of discussion. This will allow the inverviewee to feel more comfortable and not only be more collaborative with the interview, but have a better feeling of the project.
  • The interviewer should ask unbiased questions such as “Do you think that the current system serves its purpose well” instead of “Why do you think the system is no good”. Tape recording may be an interesting option. However, one must check if it doesn’t go against the company’s policy as well as ask if the interviewee doesn’t mind. One should also be political about taping. Should say that there time is very important and taping would reduce the number of questions that you may ask later INSTEAD of saying that you are taping to make sure they don’t change there mind. Separate facts from opinions. A frequent opinion of the intervewee is that he/she is overloaded with work. It is important that the interviewer shows the interviewee self-confidence. If the interviewer shows signs of fear or lack of enthusiasm, the interviewee will feel the same
  • It is important to write down a summary of the interview ASAP. If one takes too long to do so, one might forget important parts of the interview.
  • For complex tasks, an interesting technique may be observing the professional perform their regular activities and observe some intrinsic characteristics that can’t be observed otherwise. In certain scenarios, one may want to apply VERBAL PROTOCOLS. In Verbal Protocols, one tries to go inside the mind of somebody that is performing a certain task. To do this, we must encourage them to think aloud. There is literature on how to best do this.
  • A main problem with Verbal Protocols is that people react different when they are being observed. Therefore it is crucial that you explain to the person being observed that they are not the subject of the evaluation. They are just being observed in order to improve the process. Nevertheless, my experience is that some people will still not believe you, while some people will. It is preferred that more spontaneous individuals are chosen for observation. Also, you must check on the laws, IRB, and normally it is required that the person who is being observed signs a waiver agreeing to it.
  • Research is an interesting option also. Suppose you are going to develop a stock market analysis program or a point of sale program. A quick way to find out about the subject (even before you interview the client) is to download and run software similar to the one you want to design and implement.
  • Questionnaires allow us to reach a huge number of individuals. When we are referring to questionnaires, we are not referring to questions that can be elaborated for the interview, but questions that are sent alone.
  • Questionnaires lack flexibility and they typically have a very low response rate.
  • JAD or Group interview may be an interesting option. JAD (Joint Application Development) is a term proposed by IBM and it is basically a structured form of group interview where all stakeholders participate (developers, end-users, managers, etc.). My experience with this is that JAD will apply better depending on what type of organization. We did JAD when I worked for the Brazilian Navy and the higher ranked officers dominated the conversation while the lower ranked officers that were really more familiar with the work to be developed shied away from giving their opinion due to the high level of hierarchical power.
  • 09-11-2008.ppt

    1. 1. 09-11-2008, Thursday <ul><li>Class </li></ul><ul><ul><ul><li>Will </li></ul></ul></ul><ul><ul><ul><ul><ul><li>Start </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Momentarily… </li></ul></ul></ul></ul></ul>CS8630 Dr. Mario Guimaraes Database Planning, Selecting DBMS, Case Tools and Fact Finding
    2. 2. Database Planning <ul><li>Database planning should include development of standards that govern: </li></ul><ul><ul><li>how data will be collected, </li></ul></ul><ul><ul><li>how the format should be specified, </li></ul></ul><ul><ul><li>what necessary documentation will be needed, </li></ul></ul><ul><ul><li>how design and implementation should proceed. </li></ul></ul><ul><ul><li>Main Stages: Conceptual: defining the info. Without worrying about a model, </li></ul></ul><ul><ul><li>Logical: convert to tables without worrying about how it is stored, </li></ul></ul><ul><ul><li>Physical: how data is stored: int, varchar, float, etc. </li></ul></ul>
    3. 3. Database System Definition <ul><li>Describes scope and boundaries of database application and the major user views. </li></ul><ul><li>User view defines what is required of a database application from perspective of: </li></ul><ul><ul><li>a particular job role (such as Manager or Supervisor) or </li></ul></ul><ul><ul><li>enterprise application area (such as marketing, personnel, or stock control). </li></ul></ul>
    4. 4. Integrating user views
    5. 5. DBMS Selection
    6. 6. DBMS Selection <ul><li>Volume Estimates </li></ul><ul><li>Data Usage: entered, retrieved, deleted, updated </li></ul><ul><li>Response Time Requirements </li></ul><ul><li>Requirements for security, backup, recovery, </li></ul><ul><li>retention, integrity </li></ul><ul><li>Scalability </li></ul><ul><li>Interaction with other systems </li></ul><ul><li>Existing platforms ? </li></ul><ul><li>Need to run in specific OS ? </li></ul>
    7. 7. Weighted Factor Scoring Model
    8. 8. Selecting a DBMS <ul><li>http://www.dbmsmag.com/9607d11.html </li></ul><ul><li>http://www.craigsmullins.com/dbta_010.htm </li></ul><ul><li>Enterprise, Departmental, Personal or Mobile ? </li></ul><ul><li>Examples of DBMS </li></ul><ul><li>Mobile: Oracle Lite, Sybase’s Ultralite </li></ul><ul><li>Personal: MS-Access, Filemaker Pro </li></ul><ul><li>Departmental: MySQL, POSTGRES, MS-SQL Server, </li></ul><ul><li>Sybase, INFORMIX (possibly enterprise also) </li></ul><ul><li>Enterprise: Oracle, DB2, MS-SQL Server, </li></ul>
    9. 9. CASE Tools <ul><li>COMPUTER AIDED SOFTWARE ENGINEERING (CASE) </li></ul><ul><li>Example: write in QBE, code comes out in SQL. </li></ul><ul><li>Support provided by CASE tools include: </li></ul><ul><ul><li>- data dictionary to store information about database application’s data; </li></ul></ul><ul><ul><li>- design tools to support data analysis; </li></ul></ul><ul><ul><li>- tools to permit development of corporate data model, and conceptual and logical data models; </li></ul></ul><ul><ul><li>- tools to enable prototyping of applications. </li></ul></ul>
    10. 11. CASE <ul><li>Provide following benefits: </li></ul><ul><ul><li>standards; </li></ul></ul><ul><ul><li>integration; </li></ul></ul><ul><ul><li>support for standard methods; </li></ul></ul><ul><ul><li>consistency; </li></ul></ul><ul><ul><li>automation . </li></ul></ul><ul><ul><li>Quick prototypes, good for learning </li></ul></ul><ul><li>Problems </li></ul><ul><ul><li>- Lack of Integration between high end and </li></ul></ul><ul><ul><li>low end case. </li></ul></ul><ul><ul><li>Not always good for modifying </li></ul></ul><ul><ul><li>May lack flexibility </li></ul></ul><ul><ul><li>- Silver bullet syndrome </li></ul></ul>
    11. 12. CRUD Matrix How much will a CASE tool accelerate the construction of each of these Forms/Programs below ?
    12. 13. Prototypes <ul><li>Building working model of a database application. </li></ul><ul><li>Purpose </li></ul><ul><ul><li>to identify features of a system that work well, or are inadequate; </li></ul></ul><ul><ul><li>to suggest improvements or even new features; </li></ul></ul><ul><ul><li>to clarify the users’ requirements; </li></ul></ul><ul><ul><li>to evaluate feasibility of a particular system design. </li></ul></ul>
    13. 14. Fact Finding <ul><li>Formal process of using techniques such as interviews and questionnaires to collect facts about systems, requirements, and preferences . </li></ul>
    14. 15. Fact-Finding Techniques <ul><li>Database developer normally uses several fact-finding techniques during a single database project including: </li></ul><ul><ul><li>examining documentation, </li></ul></ul><ul><ul><li>interviewing, </li></ul></ul><ul><ul><li>Group interview, JAD </li></ul></ul><ul><ul><li>observing organization in operation, </li></ul></ul><ul><ul><li>research, </li></ul></ul><ul><ul><li>questionnaires. </li></ul></ul><ul><li>Which method above is the most commonly used ? </li></ul>
    15. 16. Documents
    16. 17. Interviews <ul><li>Most commonly used, and normally most useful, fact-finding technique. </li></ul><ul><li>Enables collection of information from individuals face-to-face. </li></ul><ul><li>Objectives include finding out facts, verifying facts, clarifying facts, generating enthusiasm, getting end-user involved, identifying requirements, and gathering ideas and opinions. </li></ul>
    17. 18. Interview: Advantage/Disadvantage
    18. 19. Phases in an Interview <ul><li>Selecting Interviewees: who to interview </li></ul><ul><li>Designing Interview Questions: open ended, </li></ul><ul><ul><ul><ul><li>closed ended questions, etc. </li></ul></ul></ul></ul><ul><li>Preparing for the Interview </li></ul><ul><li>Conducting the Interview </li></ul><ul><li>Post-Interview Follow-up </li></ul>
    19. 20. Preparing for an Interview <ul><li>Prepare General Interview Plan </li></ul><ul><ul><li>List of Question </li></ul></ul><ul><ul><li>Anticipated Answers and Follow-Ups </li></ul></ul><ul><ul><ul><li>Confirm Areas of Knowledge </li></ul></ul></ul><ul><ul><ul><li>Set Priorities in Case of Time Shortage </li></ul></ul></ul><ul><ul><ul><li>Prepare the Interviewee </li></ul></ul></ul><ul><ul><li>Schedule </li></ul></ul><ul><ul><li>Inform of Reason for Interview </li></ul></ul><ul><ul><li>Inform of Areas of Discussion </li></ul></ul>
    20. 21. Conducting an Interview <ul><li>Appear professional and unbiased </li></ul><ul><li>Record all information </li></ul><ul><li>Check on organizational policy regarding tape recording </li></ul><ul><li>Be sure you understand all issues and terms </li></ul><ul><li>Separate facts from opinions </li></ul><ul><li>Give interviewee time to ask questions </li></ul><ul><li>Be sure to thank the interviewee </li></ul><ul><li>End on time </li></ul><ul><li>Tips: Don’t Worry, Be Happy, Pay Attention, Summarize Key Points, </li></ul><ul><li>Be Succinct, Be Honest, Watch Body Language </li></ul>
    21. 22. Post Interview <ul><li>Prepare Interview Notes </li></ul><ul><li>Prepare Interview Report </li></ul><ul><li>Look for Gaps and New Questions </li></ul>
    22. 23. Observation <ul><li>Effective technique for understanding system. </li></ul><ul><li>Possible to participate in, or watch, a person perform activities to learn about system. </li></ul><ul><li>Useful when validity of data collected is in question or when complexity of certain aspects of system prevents clear explanation by end-users. </li></ul><ul><li>Example: studying how a student learns through VERBAL PROTOCOLS. </li></ul>
    23. 24. Adv./Dis. Of Observation
    24. 25. Research
    25. 26. Questionnaires <ul><li>Conduct surveys through questionnaires – special-purpose documents that allow facts to be gathered from a large number of people while maintaining some control over their responses. </li></ul><ul><li>Two types of questions, namely free-format and fixed-format. </li></ul>
    26. 27. Questionnaires
    27. 28. JAD or Group Interview <ul><li>ADVANTAGES </li></ul><ul><li>one user may get idea from other user. </li></ul><ul><li>Avoids redundancy in interview </li></ul><ul><li>Saves interviewer’s time </li></ul><ul><li>DISADVANTAGE </li></ul><ul><li>one user hogs conversation </li></ul><ul><li>hierarchical structure of organization </li></ul><ul><li>may not allow some users to speak freely. </li></ul>
    28. 29. End of Lecture <ul><li>End </li></ul><ul><li>Of </li></ul><ul><li>Today’s </li></ul><ul><li>Lecture. </li></ul>