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

nt Set 1

1. Describe the following: o IT and Organizational Structures Answer:

IT and Organizational Structures Traditional organizations are hierarchical, flat or matrix in design. (Fig. 1.1) In hierarchical organizations, middle managers tell subordinates what to do and tell superiors the outcomes. IS supports this hierarchy.
In flat structured organizations, work is more flexible and employees do whatever is needed. It allows off-loading extra work and supports intra-firm communications. In matrix organizations, work is organized into small work groups and integrated regionally and nationally/globally. It reduces operating complexes and expenses by allowing information to be easily shared among different managerial functions. Hierarchical Organizational Structure It is based on the concepts of division of labor, specialization, and unity of command. Key decisions are made at the top and filter down through the organization. Middle managers do the primary information processing and communication function. It is typically used to store and communicate information along the lines of the hierarchy and to support the info management function of the managers. Flat Organizational Structure Decision-making is centralized As everyone does whatever needs to be done, they can respond quickly to dynamic, uncertain environments However, this organizational structure often becomes less flexible as the organization grows. Routine work is often off-loaded but, as a hierarchy develops, becomes the glue tying parts of the organization that would not otherwise communicate. Matrix Organizational Structure This typically assigns workers with two or more supervisors in an effort to make sure that multiple dimensions of the business are integrated, with each supervisor directing a different aspect of the employees work. Matrix organizations often fail to enable managers to achieve their business strategies because of the inability to cope with increased information processing demands. Networked Organizational Structure Rigid hierarchies are replaced with formal and informal communication networks that connect all parts of the company.

Defined by their ability to promote creativity and flexibility while maintaining operational process control, which is achieved by substituting hierarchical controls with controls based on IS. Extensive use of communication technologies and networks also makes it easier to co-ordinate across functional boundaries. T-Form Organization T-form (Technology-based) organizations take the networked structure one step further by combining IT with traditional components to form new types of components. These include electronic linking, production automation, electronic workflows, electronic customer/supplier relationships and self-service Internet portals. Work is often co-ordinated electronically, while systems enable information to more easily move around the organization, and decentralizing decision-making.

2. Describe the Software cost estimation methods and guidelines Answer:

Software Cost Estimation Methods A number of methods have been used to estimate software costs Algorithimic Models These methods provide one or more algorithms which produce a software cost estimate as a function of a number of variables which relate to some software metric (usually its size) and cost drivers. Expert Judgement This method involves consulting one or more experts, perhaps with the aid of an expertconsensus mechanism such as the Delphi technique AnalogyEstimation This method involves reasoning by analogy with one or more completed projects to relate their actual costs to an estimate of the cost of a similar new project. Top-Down Estimation An overall cost estimate for the project is derived from global properties of the software product. The total cost is then split up among the various components. Bottom-Up Estimation Each component of the software job is separately estimated, and the results aggregated to produce an estimate for the overall job. Parkinson's Principle A Parkinson principle ('Work expands to fill the available volume") is invoked to equate the cost estimate to the available resources. Price to Win The cost estimation developed by this method is equated to the price believed necessary to win the job. The estimated effort depends on the customer's budget and not on the software functionality Bottom-Up Estimation Each component of the software job is separately estimated, and the results aggregated to produce an estimate for the overall job. Cost Estimation Guidelines 1. Assign the initial estimating task to the final developers. 2. Delay finalizing the initial estimate until the end of a thorough study. 3. Anticipate and control user changes.

4. Monitor the progress of the proposed project. 5. Evaluate proposed project progress by using independent auditors. 6. Use the estimate to evaluate project personnel. 7. Computing management should carefully approve the cost estimate. 8. Rely on documented facts, standards, and simple arithmetic formulas rather than guessing, intuition, personal memory, and complex formulas. 9. Don't rely on cost estimating software for an accurate estimate.

3. Describe the following: o Risk Categories o Risk components and Drivers o Risk Prioritization Answer: 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. 14. Risk Components and Drivers Risk components are defined as follows:

The degree of uncertainty that the product will meet its requirements andbe fit for its intended use.

The degree of uncertainty that the project budget will be maintained.

The degree of uncertainty that the result software will be easy to correct,adapt and enhance.

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 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.

Book ID: B 0959

1. Describe the following: o Project Metrics o Earned Value Analysis (EVA) Answer:
Project Metrics Software Metric is a measure of some property of a piece of software or its specifications. Since quantitative methods have proved so powerful in the other sciences, computer science practitioners and theoreticians have worked hard to bring similar approaches to software development. Tom DeMarco stated, You cant control what you can't measure. Common software metrics include: Order of growth (See Analysis of algorithms in terms of Asymptotic analysis and Big O notation)
Source lines of code Cyclomatic complexity Function point analysis

Bugs per line of code Code coverage Number of lines of customer requirements. Number of classes and interfaces Robert Cecil Martins software package metrics Cohesion Coupling Limitations It is very difficult to satisfactorily define or measure "how much" software there is in a program, especially when making such a prediction prior to the detail design. The practical utility of software metrics has thus been limited to narrow domains where the measurement process can be stabilized. Management methodologies such as the Capability Maturity Model or ISO 9000 have therefore focused more on process metrics which assist in monitoring and controlling the processes that produce the software. Examples of process metrics affecting software: Number of times the program failed to rebuild overnight Number of defects introduced per developer hour Number of changes to requirements Hours of programmer time available and spent per week Number of patch releases required after first product ship

Earned Value Analysis (EVA) Earned Value Analysis (EVA) is an industry standard method of measuring a project's progress at any given point in time, forecasting its completion date and final cost, and analyzing variances in the schedule and budget as the project proceeds. It compares the planned amount of work with what has actually been completed, to determine if the cost, schedule, and work accomplished are progressing in accordance with the plan. As work is completed, it is considered "earned. EVA is a snapshot in time, which can be used as a management tool as an early warning system to detect deficient or endangered progress. It ensures a clear definition of work prior to beginning that work. It provides an objective measure of accomplishments, and an early and accurate picture of the contract status. It can be as simple as tracking an elemental cost estimate breakdown as a design progresses from concept through to 100% construction documents, or it can be calculated and tracked using a seriesof mathematical formulae (see below). In either case, it provides a basis for course correction. It answers two key questions: 1. At the end of the project, is it likely that the cost will be less than, equal to or greater than the original estimate?
2. Will the project likely be completed on time? Calculating Earned Value Earned Value Management measures progress against a baseline. It involves calculating three key values for each activity in the WBS: (Work Breakdown Structure)

1. The Planned Value (PV), (formerly known as the budgeted cost of work scheduled or BCWS) that portion of the approved cost estimate planned to be spent on the given activity during a given period. 2. The Actual Cost (AC), (formerly known as the actual cost of work performed or ACWP) the total of the costs incurred in accomplishing work on the activity in a given period. This Actual Cost must correspond to whatever was budgeted for the Planned Value and the Earned Value (e.g. all labor, material, equipment, and indirect costs). 3. The Earned Value (EV), (formerly known as the budget cost of work performed or BCWP) the value of the work actually completed. These three values are combined to determine at that point in time whether or not work is being accomplished as planned. The most commonly used measures are the cost variance: Cost Variance (CV) = EV - AC and the schedule variance: Schedule Variance (SV) = EV - PV These two values can be converted to efficiency indicators to reflect the cost and schedule performance of the project. The most commonly used cost-efficiency indicator is the Cost Performance Index (CPI). It is calculated as, CPI = EV / AC The sum of all individual EV budgets divided by the sum of all individual ACs is known as the cumulative CPI, and is generally used to forecast the cost to complete a project. The Schedule Performance Index (SPI), calculated thus: SPI = EV / PV is often used with the CPI to forecast overall project completion estimates. A negative Schedule Variance (SV) calculated at a given point in time means the project is behind schedule, while a negative Cost Variance (CV) means the project is over budget.

2. Explain the following Software design concepts: o Abstraction o Refinement o Modularity o Control Hierarchy Answer: 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 implementationoriented 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.

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 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 intosub-problems, 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 o Formal Specification Languages Answer:
Mathematics in Software Development Mathematics has many useful properties for the developers of large systems. One of its most useful properties is that it is capable of succinctly and exactly describing a physical situation, an object or the outcome of an action. Ideally, the software engineer should be in the same position as the applied mathematician. A mathematical specification of a system should be presented, 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 software engineering 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 exact medium there is little possibility of ambiguity: Specifications can be mathematically validated for contradictions and incompleteness, 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 and system 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 exhibits the properties of a model, providing only sufficient details to enable the task in hand to be carried out. Finally, mathematics provides a high level of validation when it is used as a software development medium. It is possible to use a mathematical proof to demonstrate that a design matches a specification and that some program code is a correct reflection of a design. This is preferable to current practice, where often little effort is put into early validation and where much of the checking of a software 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 notation associated with sets and sequences and the logical notation used in predicate calculus. The intent of the section is to provide a brief introduction. For a more detailed discussion the reader is urged to examine books dedicated to these subjects (e.g., [WIL87], [GRI93], and [ROS95]).

Sets and Constructive Specification A set is a collection of objects or elements and is used as a cornerstone of formal methods. The elements contained within a set are 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 five programming languages. The order in which the elements appear within a set is immaterial. The number of items in a set is known 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 two ways of defining a set. A set may be defined by enumerating its elements (this is the way in which the sets just noted have been defined). The second approach is to create a constructive set specification. The general form of the members of a set is specified using a Boolean expression. Constructive set specification is preferable to enumeration because it enables a succinct definition of large sets. It also explicitly defines the rule that was used in constructing the set. Consider the following constructive 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 (a Boolean 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 indicates that only natural numbers less than 3 are to be included; and the term specifies that each element of the set will be of the form n. Therefore, this specification defines the set {0, 1, 2} When the form of the elements of a set is obvious, the term can be omitted. For example, the preceding set could be specified as (n : _ | n < 3} All the sets that have been described here have elements that are single items. Sets can also be made from elements that are pairs, triples, and so on. For example, the set specification {x, y : _ | x + y = 10 . (x, y2)} describes the set of pairs of natural numbers that have the form (x, y2) and where the sum of x and y is 10. This is the set { (1, 81), (2, 64), (3, 49), . . .} Obviously, a constructive set specification required to represent some component of computer software can be considerably more complex than those noted here. How ever the basic form and structure remains the same.

Formal Specification Languages

A formal specification language is usually composed of three primary components: (1) a syntax that defines the specific notation with which the specification is represented, (2) semantics to help define a "universe of objects" [WIN90] that will be used to describe the system, and (3) a set of relations that define the rules that indicate which objects properly satisfy the specification. The syntactic domain of a formal specification language is often based on a syntax that is derived from standard set theory notation and predicate calculus. For example, variables such as x, y, and z describe a set of objects that relate to a problem (sometimes called the domain of discourse) and are used in conjunction with the operators described in Section 25.2. Although the syntax is usually symbolic, icons (e.g., graphical symbols such as boxes, arrows, and circles) can also be used, if they are unambiguous. The semantic domain of a specification language indicates how the language represents system requirements. For example, a programming language has a set of formal semantics that enables the software developer to specify algorithms that transform input to output. A formal grammar (such as BNF) can be used to describe the syntax of the programming language. However, a programming language does not make a good specification language because it can represent only computable functions. A

specification language must have a semantic domain that is broader; that is, the semantic domain of a specification language must be capable of expressing ideas such as, "For all x in an infinite set A, there exists a y in an infinite set B such that the property P holds for x and y" [WIN90]. Other specification languages apply semantics that enable the specification of system behavior. For example, a syntax and semantics can be developed to specify states and state transition, events and their effect on state transition, synchronization and timing. It is possible to use different semantic abstractions to describe the same system in different ways. Data flow and corresponding processing were described using the data flow diagram, and system behavior was depicted with the state transition diagram. Analogous notation was used to describe object-oriented systems. Different modeling notation can be used to represent the same system. The semantics of each representation provides complementary views of the system. To illustrate this approach when formal methods are used, assume that a formal specification language is used to describe the set of events that cause a particular state to occur in a system. Another formal relation depicts all functions that occur within a given state. The intersection of these two relations provides an indication of the events that will cause specific functions to occur. A variety of formal specification languages are in use today. CSP ([HIN95], [HOR85]), LARCH [GUT93], VDM [JON91], and Z ([SPI88], [SPI92]) are representative formal specification languages that exhibit the characteristics noted previously. In this chapter, the Z specification language is used for illustrative purposes. Z is coupled with an automated tool that stores axioms, rules of inference, and application-oriented theorems that lead to mathematical proof of correctness of the specification. The decision to use of formal methods in the real world is not one that is taken lightly. Bowan and Hinchley [BOW95] have coined the ten commandments of formal methods as a guide for those who are about to apply this important software engineering approach.