What is Risk?
What is Disaster Prevention and Mitigation?
Risk is the probability that a hazard will turn into a disaster. Vulnerability and hazards are not dangerous, taken
separately. But if they come together, they become a risk or, in other words, the probability that a disaster will
happen.
Nevertheless, risks can be reduced or managed. If we are careful about how we treat the environment, and if we are
aware of our weaknesses and vulnerabilities to existing hazards, then we can take measures to make sure that
hazards do not turn into disasters.

5 software risks:
a.)Staff Turnover: This kind of software can affect the success or failure of a project since in this situation. the working staff leave before the project is finished, so we can just imagine the scenario when there is staff turnover, so the whole project and the management will be put in "hot water".
b.) The project itself: This kind of software risks include inadequate configuration control, cost overruns and poor quality. Poor quality means the software either does not work very well, or it fails in operation repeatedly. So this is problem once it is encounter.
c.) Commercial software risks: A finished project may have lower user satisfaction. Lower user satisfaction means the product has low quality, functions inadequately, and has complex structures. Users are also displeased by excessive utilization of disk space or other hardware components requirements by the software.
d.) Hardware Unavailability: A kind of sofware risk where the needed hardware specifically needed of a certain project is not available on a certain schedule that is set that it would be use.
e.) Configuring the Project: This simply means that the project might be in jeopardy once the congifure is mistaken and there will be a great need for the project to reconstruct it again.

IDENTIFY RISKS MANAGEMENT STRATEGIES

Risk management is the identification, assessment, and prioritization of risks followed by coordinated and economical application of resources to minimize, monitor, and control the probability and/or impact of unfortunate events. In such cases, there are strategies or techniques as for to guide on how to deliberate certain risks.
Identify, characterize, and assess threats.
Assess the vulnerability of critical assets to specific threats.
Determine the risk (i.e. the expected consequences of specific types of attacks on specific assets).
Identify ways to reduce those risks.
Prioritize risk reduction measures based on a strategy.

Discussion: # 4 & # 5.

IT121

Software engineering

application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software.

The term software engineering first appeared in the 1968 NATO Software Engineering Conference and was meant to provoke thought regarding the current "software crisis" at the time. Since then, it has continued as a profession and field of study dedicated to creating software that is of higher quality, more affordable, maintainable, and quicker to build. Since the field is still relatively young compared to its sister fields of engineering, there is still much debate around what software engineering actually is, and if it conforms to the classical definition of engineering. It has grown organically out of the limitations of viewing software as just programming. "Software development" is a much used term in industry which is more generic and does not necessarily subsume the engineering paradigm. Although it is questionable what impact it has had on actual software development over the last more than 40 years, the field's future looks bright according to Money Magazine and Salary.com who rated "software engineering" as the best job in America in 2006.

What is a CASE Environment? Our Definition of CASE Many definitions and descriptions of CASE exist. We choose a broad definition, perhaps the most straightforward one possible: CASE is the use of computer-based support in the software development process. This definition includes all kinds of computer-based support for any of the managerial, administrative, or technical aspects of any part of a software project. What Is a CASE Tool? Since the early days of writing software, there has been an awareness of the need for automated tools to help the software developer. Initially the concentration was on program support tools such as translators, compilers, assemblers, macro processors, and linkers and loaders. However, as computers became more powerful and the software that ran on them grew larger and more complex, the range of support tools began to expand. In particular, the use of interactive time-sharing systems for software development encouraged the development of program editors, debuggers, code analyzers, and program-pretty printers. As computers became more reliable and in greater use, the need for a broader notion of software development became apparent. Software development came to be viewed as: A large-scale activity involving significant effort to establish requirements, design an appropriate solution, implement that solution, test the solution's correctness, and document the functionality of the final system. A long-term process producing software that requires enhancement through out its lifetime. The implications of this are that the structure of the software must enable new functionality to be added easily, and detailed records of the requirements, design, implementation, and testing of the system must be kept to aid maintainers of the software. In addition, multiple versions of all artifacts produced during a project must be maintained to facilitate group development of software systems. A group activity involving interaction among a number of people during each stage of its life. Groups of people must be able to cooperate, in a controlled manner, and have consistent views of the state of the project. This view of "programming in the large" resulted in a wide range of support tools being developed. Initially, the tools were not very sophisticated in their support. However, two important advances had the effect of greatly improving the sophistication of these tools: Research in the area of software development processes gave rise to a number of software design methods (e.g., Jackson Structured Programming, the Yourdon Method) that could be used as the basis for software development. These methods were ideally suited to automated tool support in that they required step-by-step adherence to methods, had graphical notations associated with them, and produced a large number of artifacts (e.g., diagrams, annotations, and documentation) that needed to be recorded and maintained. .....personal workstations and personal computers. These machines have relatively large memory storage capacities, fast processors, and sophisticated bit-mapped graphics displays that are capable of displaying charts, graphical models, and diagrams. We refer to all of the above tools as CASE tools and posit the following definition: A CASE tool is a computer-based product aimed at supporting one or more software engineering activities within a software development process. What Is a CASE Environment? The first generation of CASE tool developers concentrated to a large extent on the automation of isolated tasks such as document production, version control of source code, and design method support. While successes have been achieved in supporting such specific tasks, the need for these `islands of automation' to be connected has been clearly recognized by many first generation CASE tool users. For example, a typical development scenario requires that designs be closely related to their resultant source code, that they be consistently described in a set of documentation, and that all of these artifacts be under centralized version control. The tools that support the individual tasks of design, coding, documentation, and version control must be integrated if they are to support this kind of scenario effectively. In fact, such tools are more often used as components in a much more elaborate software development support infrastructure that is available to software engineers. A typical CASE environment consists of a number of CASE tools operating on a common hardware and software platform. Also note that there are a number of different classes of users of a CASE environment. Some users, such as software developers and managers, wish to make use of CASE tools to support them in developing application systems and monitoring the progress of a project. On the other hand, tool integrators are responsible for ensuring that the tools operate on the software and hardware platform available, and the system administrator's role is to maintain and update the hardware and software platform itself. Also note that software developers, tool integrators, and system administrators interact with multiple CASE tools and environment components that form the software and hardware platform of the CASE environment. It is these interactions, among the different CASE environment components and between users and those components, that are the key elements of a CASE environment. In many respects the approach toward the management, control, and support of these interactions distinguishes one CASE environment from another. We can define a CASE environment by emphasizing the importance of these interactions: A CASE environment is a collection of CASE tools and other components together with an integration approach that supports most or all of the interactions that occur among the environment components, and between the users of the environment and the environment itself. The critical part of this definition is that the interactions among environment components are supported within the environment. What distinguishes a CASE environment from a random amalgamation of CASE tools is that there is some thing that is provided in the environment that facilitates interaction of those tools. This `something' may be a physical mechanism such as a shared database or a message broadcast system, a conceptual notion such as a shared philosophy on tool architectures or common semantics about the objects the tools manipulate, or some combination of these things. The range of possible ways of providing the `glue' that links CASE tools together inevitably leads to a spectrum of approaches to implementing a CASE environment. One of the main points we make in this book is that there are many ways to build a CASE environment. While many people concentrate on the selection of CASE tools and components when assembling a CASE environ ment, they largely ignore the need to support the interactions among those components. We concentrate less on which components should be chosen, and much more on how the selected components can be made to work together effectively. Whether a chosen approach to component interaction is appropriate in a given context will depend on many overlapping factors: the needs of the organization in question, the available resources, and so forth. A detailed assessment of these related factors and constraints is necessary to determine the CASE environment most suited to the problem at hand. The Software Engineering Institute (SEI) is a federally funded research and development center sponsored by the U.S. Department of Defense and operated by Carnegie Mellon University. Copyright 2007 by Carnegie Mellon University Terms of Use URL: http://www.sei.cmu.edu/legacy/case/case_whatis.html Last Modified: 11 January 2007 reference: www.yahoo.com