Master of Computer Application (MCA) Semester V MC0084 SPM & QA 4 Credits (Book ID: B 0958) Assignment Set 1

3. Describe the following: *Risk Categories *Risk components and Drivers *Risk Prioritization

Risk Categories : Risk management is an essential activity of project management. It is important to classify risks intoappropriate categories. Risks can be classified into following 13 categories: 1. Operational Risk: Risks of loss due to improper process implementation, failed system or someexternal events risks. Examples can be Failure to address priority conflicts, Insufficient resources or Noproper subject training etc. 2. Schedule Risk: Project schedule get slip when project tasks and schedule release risks are notaddressed properly. Schedule risks mainly affect on project and finally on company economy and maylead to project failure 3. Budget Risk: Wrong budget estimation or Project scope expansion leads to Budget / Cost Risk. Thisrisk may lead to either a delay in the delivery of the project or sometimes even an incomplete closureof the project. 4. Business Risk: Non-availability of contracts or purchase order at the start of the project or delay inreceiving proper inputs from the customer or business analyst may lead to business risks. 5. Technical Environment Risk: These are the risks related to the environment under which both theclient and the customer work. For example, constantly changing development or production or testingenvironment can lead to this risk. 6. Information Security Risk: The risks related to the security of information like confidentiality orintegrity of customers personal / business data. The Access rights / privileges failure will lead toleakage of confidential data. 7. Programmatic Risks: The external risks beyond the operational limits. These are outside the controlof the program. These external events can be Running out of fund or Changing customer productstrategy and priority or Government rule changes etc. 8. Infrastructure Risk: Improper planning of infrastructure / resources may lead to risks related toslow network connectivity or complete failure of connectivity at both the client and the customer sites.So, it is important to do proper planning of infrastructure for the efficient development of a project. 9. Quality and Process Risk: This risk occures due toIncorrect application of process tailoring and deviation guidelinesNew employees allocated to the project not trained in the quality processes and procedures adoptedby the organization 10. Resource Risk: This risk depends on factors like Schedule, Staff, Budget and Facilities. Impropermanagement of any of these factors leads to resource risk.

11. Supplier Risk: This type of risk may occurs when some third party supplier is involved in thedevelopment of the project. This risk occurs due to the uncertain or inadequate capability of supplier. 12. Technology Risk: It is related to the complete change in technology or introduction of a newtechnology. 13. Technical and Architectural Risk: These types of risks generally generally leads to failure of functionality and performance. It addresses the hardware and software tools & supporting equipmentsused in the project. The risk for this category may be due to Capacity, Suitability, usability,Familiarity, Reliability, System Support and deliverability. *Risk Components and Drivers Risk components are defined as follows: Performance risk: The degree of uncertainty that the product will meet its requirements andbe fit for its intended use. Cost risks: The degree of uncertainty that the project budget will be maintained. Support risks: The degree of uncertainty that the result software will be easy to correct,adapt and enhance. Schedule risks: The degree of uncertainty that the project schedule will be maintained andthat the product will be delivered on time. *Risk Prioritization The identified risks for a project merely give the possible events that can hinder it from meeting the goal. The consequences of various risks, however, may differ. So before we proceed with management risks, project mangers prioritize them so that management energies can be focused on high risks. Prioritization requires analyzing the possible side effects of the risk event in case it actually occurs. Based on the possible consequences and the probability of the risks event occurring, you can compute the risk exposure, which you can then use for prioritizing risks. In risk prioritization, each identified risk is evaluated and assigned values for The following elements:The probability that the risk condition will actually occur The impact if the risk condition does occur The risk exposure Multiplying the risk probability by the impact would yield risk exposure, which is then compared against all other risk exposures to determine which risk will be given priority for risk mitigation .Since exposure is a relative measurement based on the numeric value assigned to risk probability and impact, consistency in assigning the probability and impact values is critical. A prioritized risks list that ranks risks by their exposure value determines the order in which risks will be addressed in risk mitigation and contingency planning. 2. Explain the following Software design concepts: o Abstraction o Refinement o Modularity o Control Hierarchy

Ans:Design Concepts A set of fundamental software design concepts has evolved over the past four decades. Although the degree of interest in each concept has varied over the years, each has stood thetest of time. Each provides the software designer with a foundation from which moresophisticated design methods can be applied. Each helps the software engineer to answer thefollowing questions.What criteria can be used to partition software into individual components?How function or data structure detail is separated from a conceptual representation of thesoftware?What uniform criteria define the technical quality of a software design? Abstraction:When we consider a modular solution to any problem, many levels of Abstraction can be posed. At the highest level of abstraction, a solution is Stated in broad terms using the language of theproblem environment. Atlower levels of abstraction, a more procedural orientation is taken.Problemoriented terminology is coupled with implementation-oriented terminology in an effort tostate a solution. Finally, at the lowest level of abstraction, the solution is stated in a manner thatcan be directly implemented. Wasserman [WAS83] provides a useful definition:The psychological notion of "abstraction" permits one to concentrate on a problem atsome level of generalization without regard to irrelevant low level details; use of abstraction alsopermits one to work with concepts and terms that are familiar in the problem environmentwithout having to transform them to an unfamiliar structure. Each step in the software process isa refinement in the level of abstraction of the software solution. During system engineering,software is allocated as an element of a computer-based system. During software requirementsanalysis, the software solution is stated in terms "that are familiar in the problem environment." As we move through the design process, the level of abstraction is reduced. Finally, the lowestlevel of abstraction is reached when source code is generated. As we move through differentlevels of abstraction, we work to create procedural and data abstractions. A procedural abstraction is a named sequence of instructions that has a specific andlimited function. An example of a procedural abstraction would be the word open for a door.Open implies a long sequence of procedural steps (e.g., walk to the door, reach out and graspknob, turn knob and pull door, step away from moving door, etc.). A data abstraction is a namedcollection of data that describes a data object. In the context of the procedural abstraction open,we can define a data abstraction called door. Like any data object, the data abstraction for door would encompass a set of attributes that describe the door (e.g., door type, swing direction,opening mechanism, weight, dimensions). It follows that the procedural abstraction open wouldmake use of information contained in the attributes of the data abstraction door. Many modernprogramming languages provide mechanisms for creating abstract data types. For example, the Ada package is a programming language mechanism that provides support for both data andprocedural abstraction. The original abstract data type is used as a template or generic datastructure from which other data structures can be instantiated. Control abstraction is thethird form of abstraction used in software design. Like procedural and data abstraction, controlabstraction implies a program control mechanism without specifying internal details. 2. Refinement:Stepwise refinement is a top-down design strategy originally proposed by Niklaus Aprogram is

developed by successively refining levels of procedural detail. In each step (of therefinement), one or several instructions of the given program are decomposed into moredetailed instructions. This successive decomposition or refinement of specifications terminateswhen all instructions are expressed in terms of any underlying computer or programminglanguage. As tasks are refined, so the data may have to be refined, decomposed, or structured, and it is natural to refine the program and the data specifications in parallel. Every refinementstep implies some design decisions. It is important that the programmer be aware of theunderlying criteria (for design decisions) and of the existence of alternative solutions. Theprocess of program refinement proposed by Wirth is analogous to the process of refinement andpartitioning that is used during requirements analysis. The differences that are in the level of implementation details are considered, not the approach. Refinement is actually a process of elaboration. We begin with a statement of function (or description of information) that is definedat a high level of abstraction. That is, the statement describes function or informationconceptually but provides no information about the internal workings of the function or theinternal structure of the information. Refinement causes the designer to elaborate on the originalstatement, providing more and more detail as each successive refinement (elaboration) occurs. Abstraction and refinement are complementary concepts. Abstraction enables a designer tospecify procedure and data and yet suppress low-level details. Refinement helps the designer toreveal low-level details as design progresses. Both concepts aid the designer in creating acomplete design model as the design evolves 3. Modularity:The concept of modularity in computer software has been espoused for almost fivedecades. Software architecture embodies modularity; that is, software is divided into separatelynamed and addressable components, often called modules that are integrated to satisfyproblem requirements. . It has been stated that "modularity is the single attribute of softwarethat allows a program to be intellectually manageable" [MYE78]. Monolithic software (i.e., alarge program composed of a single module) cannot be easily grasped by a reader.Howmodular should we make software? The answers to these questions require an understandingof other design concepts considered later in this chapter. Another important question ariseswhen modularity is considered. How do we define an appropriate module of a given size? Theanswer lies in the method(s) used to define modules within a system. Meyer [MEY88] definesfive criteria that enable us to evaluate a design method with respect to itsability to define an effective modular system.

Modular decomposability: If a design method provides a systematic mechanism for decomposing the problem intosubproblems, it will reduce the complexity of the overall problem, thereby achieving an effectivemodular solution Modular composability :If a design method enables existing (reusable) design components to be assembled intoa new system, it will yield a modular solution that does not reinvent the wheel. Modular understandability: If a module can be understood as a standalone unit (without reference to other modules), it will be easier to build and easier to change. Modular continuity :If small changes to the system requirements result in changes to individual modules,rather than system-wide changes, the impact of change-induced side effects will be minimized. Modular protection: If an aberrant condition occurs within a module and its effects are constrained within thatmodule, the impact of error-induced side effects will be minimized. Finally, it is important to notethat a system may be designed modularly, even if its implementation must be "monolithic."There are situations (e.g., real time software, embedded software) in which relatively minimalspeed and memory overhead introduced by subprograms (i.e., subroutines, procedures) isunacceptable. In such situations, software can and should be designed with modularity as an overriding philosophy. Code may be developed "in line." Although the program source codemay not look modular at first glance, the philosophy has been maintained and the program willprovide the benefits of a modular system. Control Hierarchy:Control hierarchy, also called program structure, represents the organization of programcomponents (modules) and implies a hierarchy of control. It does not represent proceduralaspects of software such as sequence of processes, occurrence or order of decisions, or repetition of operations; no is it necessarily applicable to all architectural styles.

Differentnotations are used to represent control hierarchy for those architectural styles that areamenable to this representation. The most common is the tree like diagram (Figure 5.2) thatrepresents hierarchical control for call and return architectures. A call and return architecture isa classic program structure that decomposes function into a control hierarchy where a mainprogram invokes a number of program components, which in turn may invoke still other components. The control relationship among modules is expressed in the following way: Amodule that controls another module is said to be super ordinate to it, and conversely, a modulecontrolled by another is said to be subordinate to the controller.
3. Describe the following Formal Methods: o Mathematics in Software Development

Mathematics has many useful properties for the developers of large systems. One of its most useful properties is that it iscapable of succinctly and exactly describing a physical situation, an object or the outcome of an action. Ideally, the softwareengineer should be in the same position as the applied mathematician. A mathematical specification of a system should bepresented, and a solution developed in terms of a software architecture that implements the specification should be produced.Another advantage of using mathematics in the software process is that it provides a smooth transition between softwareengineering activities. Not only functional specifications but also system designs can be expressed in mathematics, and of course, the program code is a mathematical notation albeit a rather long-winded one.The major property of mathematics is that it supports abstraction and is an excellent medium for modeling. As it is an exactmedium there is little possibility of ambiguity: Specifications can be mathematically validated for contradictions andincompleteness, and vagueness disappears completely.In addition, mathematics can be used to represent levels of abstraction in a system specification in an organized way.Mathematics is an ideal tool for modeling. It enables the bare bones of a specification to be exhibited and helps the analyst andsystem specifier to validate a specification for functionality without intrusion of such issues as response time, design directives,implementation directives, and project constraints. It also helps the designer, because the system design specification exhibitsthe properties of a model, providing only sufficient details to enable the task in hand to be carried out. Finally, mathematicsprovides a high level of validation when it is used as a software development medium. It is possible to use a mathematicalproof to demonstrate that a design matches a specification and that some program code is a correct reflection of a design. Thisis preferable to current practice, where often little effort is put into early validation and where much of the checking of asoftware system occurs during system and acceptance testing.Mathematical Preliminaries To apply formal methods effectively, a software engineer must have a working knowledge of the mathematical notationassociated with sets and sequences and the logical notation used in predicate calculus. The intent of the section is to provide abrief introduction. For a more detailed discussion the reader is urged to examine books dedicated to these subject Sets and Constructive SpecificationA set is a collection of objects or elements and is used as a cornerstone of formal methods. The elements contained within a setare unique (i.e., no duplicates are allowed). Sets with a small number of elements are written within curly brackets (braces)with

the elements separated by commas. For example, the set {C++, Pascal, Ada, COBOL, Java} contains the names of fiveprogramming languages. The order in which the elements appear within a set is immaterial. The number of items in a set isknown as its cardinality. The # operator returns a set's cardinality. For example, the expression #{A, B, C, D} = 4 implies that the cardinality operator has been applied to the set shown with a result indicating the number of items in the set. There are twoways of defining a set. A set may be defined by enumerating its elements (this is the way in which the sets just noted have beendefined). The second approach is to create a constructive set specification. The general form of the members of a set isspecified using a Boolean expression. Constructive set specification is preferable to enumeration because it enables a succinctdefinition of large sets. It also explicitly defines the rule that was used in constructing the set. Consider the followingconstructive specification example: {n : _ | n < 3 . n} This specification has three components, a signature, n : _, a predicate n <3, and a term, n. The signature specifies the range of values that will be considered when forming the set, the predicate (aBoolean expression) defines how the set is to be constricted, and, finally, the term gives the general form of the item of the set.In the example above, _ stands for the natural numbers; therefore, natural numbers are to be considered. The predicate indicatesthat only natural numbers less than 3 are to be included; and the term specifies that each element of the set will be of the formn.Therefore, this specification defines the set {0, 1, 2} When the form of the elements of a set is obvious, the term can beomitted. For example, the preceding set could be specified as (n : _ | n < 3} All the sets that have been described here haveelements that are single items. Sets can also be made from elements that are pairs, triples, and so on. For example, the setspecification {x, y : _ | x + y = 10 . (x, y2)} describes the set of pairs of natural numbers that have the form (x, y2) and wherethe sum of x and y is 10. This is the set { (1, 81), (2, 64), (3, 49), . . .} Obviously, a constructive set specification required torepresent some component of computer software can be considerably more complex than those noted here. How ever the basicform and structure remains the same