1 / 83

Software Engineering CIS 410 Winter 2004 Week 9 Lecture Dr. David Gadish

Software Engineering CIS 410 Winter 2004 Week 9 Lecture Dr. David Gadish. Week 8 Review. Reviewed individual project progress Operating Systems (Chapter 11) File Management Systems (Chapter 12). Week 9 Agenda. Student Presentations (10-15 min each): Adolpho, Martin, Sean

baina
Download Presentation

Software Engineering CIS 410 Winter 2004 Week 9 Lecture Dr. David Gadish

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software EngineeringCIS 410Winter 2004Week 9 LectureDr. David Gadish © 2004, David Gadish, Ph.D.

  2. Week 8 Review • Reviewed individual project progress • Operating Systems (Chapter 11) • File Management Systems (Chapter 12) © 2004, David Gadish, Ph.D.

  3. Week 9 Agenda • Student Presentations (10-15 min each): • Adolpho, Martin, Sean • Jonathan, Allan, Stephanie • System Administration (Chapter 14) • CAD Technology - Overview • GIS Technology - Overview © 2004, David Gadish, Ph.D.

  4. System Administration Chapter 14

  5. Objectives • System administration responsibilities and tasks • The process of acquiring computer hardware and system software • Tools and processes for evaluating application resource requirements and computer system performance • System security model • how it can be implemented • Installing and protecting computer hardware © 2004, David Gadish, Ph.D.

  6. Chapter Topics © 2004, David Gadish, Ph.D.

  7. System Administration System Administration responsibilities: • Acquiring new IS resources • Maintaining existing IS resources • Designing and implementing an IS security policy • Ensure the efficient and reliable delivery of information services © 2004, David Gadish, Ph.D.

  8. System Administration Strategic Planning issues: • Strategies for developing services and markets for them • Strategies for acquiring sufficient resources for operations and growth • Organizational structure and control © 2004, David Gadish, Ph.D.

  9. System Administration Hardware and Software as Infrastructure: Capital resources have the following characteristics: • Service to a large and diverse set of users • Costs that are difficult to allocate to individual users • Recurring need for new capital expenditures • Significant operating costs for maintenance © 2004, David Gadish, Ph.D.

  10. System Administration Hardware and Software as Infrastructure: The strategic issues that must be addressed by organizations are: • What services will be provided? • How will service users be charged? • What infrastructure is required to provide the services? • How can the infrastructure be operated, maintained, and improved at minimal cost? © 2004, David Gadish, Ph.D.

  11. System Administration Standards: • Providing infrastructure-based services to a wide variety of users requires adopting services standards. • Standardization causes problems for users that want services near the leading edge. • It is hard to standardize when dealing with hardware and software. © 2004, David Gadish, Ph.D.

  12. System Administration Competitive Advantage: Describes a state of affairs in which one organization employs resources so as to give it a significant advantage over its competitors. © 2004, David Gadish, Ph.D.

  13. System Administration Competitive Advantage: • Providing services that competitors are unable to provide • Providing services of unusually high quality • Providing services at unusually low price • Generating services at unusually low cost © 2004, David Gadish, Ph.D.

  14. The Acquisition Process

  15. The Acquisition Process • Determine the applications that the hardware/software will support. • Specify detailed requirements in terms of hardware and software capability and capacity. • Draft a request for proposals and circulate it to potential vendors. • Evaluate the responses to the request for proposals. • Contract with a vendor or vendors for purchase, installation, and/or maintenance. © 2004, David Gadish, Ph.D.

  16. The Acquisition Process Determining and Stating Requirements: • Integration with existing hardware/software • Availability of maintenance services • Availability of training • Physical parameters such as size, cooling requirements, and disk space for system software • Availability of upgrades © 2004, David Gadish, Ph.D.

  17. The Acquisition Process Request for Proposal (RFP) A formal document sent to vendors that states requirements and solicits proposals to meet those requirements. © 2004, David Gadish, Ph.D.

  18. The Acquisition Process Evaluating Proposals: • Determine acceptability of each proposal • Rank acceptable proposals • Validate high-ranking proposals © 2004, David Gadish, Ph.D.

  19. Determining and Evaluating Performance

  20. Determining Requirements and Evaluating Performance Determining hardware requirements for software is difficult: • Computer systems are complex combinations of interdependent components. • The configuration of operating and other system software can significantly affect raw hardware performance. • The hardware and system software resources required by applications cannot always be predicted precisely. © 2004, David Gadish, Ph.D.

  21. Determining Requirements and Evaluating Performance Benchmarks: • A measure of computer performance for specific tasks • Select the benchmark test most relevant to the intended application. • Determine the relationship between benchmark tests and the actual work that the new computer system will perform. © 2004, David Gadish, Ph.D.

  22. Determining Requirements and Evaluating Performance Measuring Resource Demand and Utilization: • Hardware monitors (between hardware components) • Software monitors (usually embedded in OS) • Program profilers (in S/W code) © 2004, David Gadish, Ph.D.

  23. Security

  24. Security Well integrated approach includes measures to: • Protect physical resources against accidental loss or damage • Protect data and software resources against accidental loss or damage • Protect all resources against malicious tampering • Protect sensitive software and data resources against unauthorized access and accidental disclosure © 2004, David Gadish, Ph.D.

  25. Security Access Control Processes: • Authentication – the process of determining or verifying the identity of a user or process owner. • Authorization - determining whether an authenticated user or process has sufficient rights to access a particular resource. © 2004, David Gadish, Ph.D.

  26. Security © 2004, David Gadish, Ph.D.

  27. Security Password Controls and Security Methods: • Restrictions on the length and composition of valid passwords • Requirements that passwords periodically be changed • Encryption of passwords in files and during transmission over a network © 2004, David Gadish, Ph.D.

  28. Security © 2004, David Gadish, Ph.D.

  29. Security © 2004, David Gadish, Ph.D.

  30. Security Auditing – the process of creating and managing records of user activity or resource access. © 2004, David Gadish, Ph.D.

  31. Security Virus Protection Software Capabilities: • Scanning e-mail messages and attachments • Monitoring access to important system files and data structures • Scanning removable media • Periodically scanning the file system © 2004, David Gadish, Ph.D.

  32. Security Software Updates: © 2004, David Gadish, Ph.D.

  33. Security © 2004, David Gadish, Ph.D.

  34. Security Firewalls: • Application firewalls – (proxy server) – a server that handles the service requests of external users. • Stateful firewalls – tracks the progress of complex client-server interactions. © 2004, David Gadish, Ph.D.

  35. Security © 2004, David Gadish, Ph.D.

  36. Physical Environment

  37. Physical Environment Computer Hardware Installation Issues: • Electrical Power • Heat Dissipation • Moisture • Cable Routing • Fire Protection © 2004, David Gadish, Ph.D.

  38. Physical Environment Electrical Power - fluctuations in power can cause: • Momentary power surges • Momentary power sags • Long-term voltage sags • Total loss of power © 2004, David Gadish, Ph.D.

  39. Physical Environment Heat Dissipation: • All computer equipment requires some means of heat dissipation. • Many hardware devices use fans to move air through the unit. • Auxiliary cooling can be provided within an individual equipment cabinet. © 2004, David Gadish, Ph.D.

  40. Physical Environment Moisture: • Excessive moisture is an enemy of electrical circuitry. • Well-designed cabinets are one defense against the dangers of moisture. • Humidity can be controlled automatically by optional components of heating, ventilation and air conditioning systems. © 2004, David Gadish, Ph.D.

  41. Physical Environment Cable Routing: A raised floor is generally used in a room that contains multiple hardware cabinets, a single mainframe computer system or multiple minicomputers. © 2004, David Gadish, Ph.D.

  42. Physical Environment Fire Protection: • Carbon dioxide, fire retardant foams and powders, and various gaseous compounds are alternate methods of fire protection, but not for computer equipment. • Halon gas is used around computer equipment since is does not promote condensation. © 2004, David Gadish, Ph.D.

  43. Physical Environment Disaster Planning and Recovery: • Periodic data backup and storage of backups at alternate sites. • Backup and storage of critical software at alternate sites. • Installing of duplicate or supplementary equipment at alternate sites. • Arrangements for leasing existing equipment at alternate sites. © 2004, David Gadish, Ph.D.

  44. Computer Aided Design (CAD)

  45. In the Beginning… • Ivan Sutherland who demonstrated a sketching program called Sketchpad in 1963. • Sketchpad allowed engineers for the first time to generate drawings by using an interactive graphics terminal, and to manipulate them by using a light pen and keyboard. • From these beginnings, the field developed rapidly.  © 2004, David Gadish, Ph.D.

  46. And then… • The first CAD systems appeared in the mid-1960s • IBM's DAC-1 for use by General Motors in car design. • Architectural uses of CAD lagged behind engineering applications. • CAD typically required investments of hundreds of thousands of dollars.  • The introduction of personal computers, particularly the IBM PC in 1981 was a turning point for architectural CAD. • In 1982, Autodesk introduced the first CAD program for the IBM PC, called AutoCAD. With this, CAD became affordable.  © 2004, David Gadish, Ph.D.

  47. Computer Aided Design • Using computers for design activities • Points, Lines, Shapes,… • Color, Line Weight, Style,… • Graphics, Attributes • 2D, 3D • Lighting, … © 2004, David Gadish, Ph.D.

  48. Computer Aided Design • Two of the major players: • Autodesk • www.autodesk.com • AutoCad software • Bentley • www.bentley.com • Microstation software © 2004, David Gadish, Ph.D.

  49. CAD Sectors • Architectural Design • Civil Engineering • Facilities Management • Geospatial (GIS) • Plant Design • Landscape Design • Automobile Design © 2004, David Gadish, Ph.D.

  50. CAD for Architectural Design © 2004, David Gadish, Ph.D.

More Related