MCA 5th Sem Assignments

SPM & QA

SPM & QA
1. Describe the following: IT and Organizational Structures IT and Organizational Structures Traditional organizations are hierarchical, flat or matrix in design . 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.
Page 1 of 16

MCA 5th Sem Assignments

SPM & QA

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 selfservice 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 Software Cost Estimation Methods A number of methods have been used to estimate software costs

Page 2 of 16

MCA 5th Sem Assignments

SPM & QA

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

Page 3 of 16

MCA 5th Sem Assignments

SPM & QA

Cost Estimation Guidelines Assign the initial estimating task to the final developers. Delay finalizing the initial estimate until the end of a thorough study. Anticipate and control user changes. Monitor the progress of the proposed project. Evaluate proposed project progress by using independent auditors. Use the estimate to evaluate project personnel. Computing management should carefully approve the cost estimate. Rely on documented facts, standards, and simple arithmetic formulas rather than guessing, intuition, personal memory, and complex formulas. Don't rely on cost estimating software for an accurate estimate.

3. Describe the following: a. 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: 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. 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 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.

Page 4 of 16

MCA 5th Sem Assignments

SPM & QA

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. 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. 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. 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. 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. 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 Resource Risk: This risk depends on factors like Schedule, Staff, Budget and Facilities. Impropermanagement of any of these factors leads to resource risk.
Page 5 of 16

MCA 5th Sem Assignments

SPM & QA

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. Technology Risk: It is related to the complete change in technology or introduction of a newtechnology. 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. b. 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.

Page 6 of 16

MCA 5th Sem Assignments

SPM & QA

c. 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 impact if the risk cond 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. 4. Describe the following: a. 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

Page 7 of 16

MCA 5th Sem Assignments

SPM & QA

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
Page 8 of 16

MCA 5th Sem Assignments

SPM & QA

Number of changes to requirements Hours of programmer time available and spent per week Number of patch releases required after first product ship

b. Earned Value Analysis (EVA) 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: At the end of the project, is it likely that the cost will be less than, equal to or greater than the original estimate? Will the project likely be completed on time?

Page 9 of 16

MCA 5th Sem Assignments

SPM & QA

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
Page 10 of 16

MCA 5th Sem Assignments

SPM & QA

behind schedule, while a negative Cost Variance (CV) means the project is over budget.

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

Page 11 of 16

MCA 5th Sem Assignments

SPM & QA

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

Page 12 of 16

MCA 5th Sem Assignments

SPM & QA

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,
Page 13 of 16

MCA 5th Sem Assignments

SPM & QA

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:

Page 14 of 16

MCA 5th Sem Assignments

SPM & QA

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 changeinduced 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:Page 15 of 16

MCA 5th Sem Assignments

SPM & QA

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.

Page 16 of 16