What do you understand by information determinacy?

With reference to software applications, Information Determinacy refers to the predictability of the order and timing of information. Determinacy is the very important factor in determining the nature of a software application. Below is the example of Information Determinacy for Determinate and Indeterminate applications. An engineering analysis program accepts data that have a predefined order, executes the analysis algorithm(s) without interruption, and produces resultant data in report or graphical format. Such applications are called determinate applications. A multi-user operating system, on the other hand, accepts inputs that have varied content and arbitrary timing, executes algorithms that can be interrupted by external conditions, and produces output that varies as a function of environment and time. Applications with these characteristics are indeterminate applications.

1. Why is it inappropriate to use reliability metrics, which were developed for hardware systems in estimating software system reliability? Illustrate your answer with an example. Ans Since Software Reliability is one of the most important aspects of software quality ,Reliability Engineering approaches are practiced in software field as well. Software Reliability Engineering (SRE) is the quantitative study of the operational behavior of softwarebased systems with respect to user requirements concerning reliability. Measuring software reliability remains a difficult problem because we don't have a good understanding of the nature of software. There is no clear definition to what aspects are related to software reliability. We cannot find a suitable way to measure software reliability, and most of the aspects related to software reliability.

It is not usually appropriate to use hardware reliability metrics because of the different types of failure which normally occurs in hardware. Most hardware system failures are a result of component failures due to faulty manufacture or because a component has come to the end of its normal life. Once a component has failed, it must be replaced or repaired before normal system services can be resumed. However, most software failures are transient and are a consequence of design errors or timing problems. The component can continue to deliver normal service without repair. Hardware metrics such as "mean time to failure" are based on component life times and therefore cannot be applied directly to software systems. An example might be a bank teller system which includes a hardware component to open the door to deliver cash and a software component to deliver signals to that door. When the hardware component fails, the whole system is out of action until that component is repaired. If the software component fails in one specific circumstance then cash may not be delivered in that case but delivery could resume with the next transaction.

2. Using examples explain the difference between object & an object class
Saved but needs to be edited.

Classes and objects are separate but related concepts. Every object belongs to a class and every class contains one or more related objects.
Ans

A Class is static. All of the attributes of a class are fixed before, during, and after the execution of a program. The attributes of a class don't change. The class to which an object belongs is also (usually) static. If a particular object belongs to a certain class at the time that it is created then it almost c e r t a i n l y wi l l s t i l l b e l o n g t o t h a t c la s s r i g h t u p u n t i l t h e t i me t h a t i t is destroyed.

An Object on the other hand has a limited lifespan. Objects are created and eventually destroyed. Also during that lifetime, the attributes of the object may undergo significant change.

So let's now use an example to clarify what the differences are between a class and an object : Let us consider the class car. Cars have a body, wheels, an engine, seats, are usedto transport people between locations, and require at least one person in the carfor it to move by its own power. These are some of the attributes of the class - car- and all members that this class has ever or will ever have share these attributes. The members of the class - car - are objects and the objects are individual andspecific cars. Each indi vidual car has a creation date (an example of an objecthaving an attribute that is static), an owner, a registered address (examples of attributes that may or may not change), a current location, current occupants,c u r r e n t f u e l l e v e l ( e x a mp l e s o f a t t r i b u t e s th a t c h a n g e q u i c k l y) , a n d i t ma y b e covered by insurance (an example of an attribute that may or may not exist). To use a more programming related example, the class window has edges, a titlebar, maximize and minimize buttons, and an area to display the window contents.A specific window has a location on the screen, a size, a title, and may or may nothave something in the content area.S o b a s i c a ll y t h e d i f f e r e n c e b e t we e n a c l a s s a n d a n o b je c t i s t h a t a c l a s s i s a general concept while objects are the specific and real instances that embody thatconcept. When creating an object oriented program we define the classes and ther e l a t i o n s h i p s b e t we e n t h e c l a s s e s . We t h e n e x e c u t e t h e p r o g r a m t o c r e a t e , update, and destroy the objects which are the specific realization of these classes.

3. Ans

What is the importance of Software Validation, in testing? From scribd http://www.scribd.com/doc/78258382/MC0071-Answered

: Software Validation Also known as software quality control.Validation checks that the product design satisfies or fits the intended usage (high-levelchecking) i.e., you built the right product. This is done through dynamic testing and other forms of review.According to the Capability Maturity Model (CMMI-SW v1.1), Verification : The process of evaluating software to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase.[IEEE-STD-610]. Validation : The process of evaluating software during or at the end of the developmentprocess to determine whether it satisfies specified requirements. In other words,validation ensures that the product actually meets the users needs, and that thespecifications were correct in the first place, while verification is ensuring that theproduct has been built according to the requirements and design specifications.Validation ensures that you built the right thing. Verification ensures that you built itright. Validation confirms that the product, as provided, will fulfill its intended use.From testing perspective: Fault wrong or missing function in the code.

Failure the manifestation of a fault during execution.

Malfunction according to its specification the system does not meet its specifiedfunctionality. Within the modeling and simulation community, the definitions of validation, verificationand accreditation are similar: Validation is the process of determining the degree to which a model, simulation, or federation of models and simulations, and their associated data are accuraterepresentations of the real world from the perspective of the intended use(s). Accreditation is the formal certification that a model or simulation is acceptable to beused for a specific purpose. Verification is the process of determining that a computer model, simulation, or federation of models and simulations implementations and their associated dataaccurately represents the developers conceptual description and specifications

4. Explain why a software system which is used in a real-world environment must change or become progressively less useful. Ans There are many reasons - new advances in technology may make an existing piece of software obsolete. For example - software need to be able to adapt to new peripherals. It's no good buying a new printer or scanner if existing software cant communicate with it .
Each and everyday new systems come to pass. they are so many other softwares which are not in the system now and you would ask yourself why they are no longer used. this is because, they can no longer tally with the new environment and hence needs to be wiped away. it should always change, with time it will render non-functional and would not serve any better purpose rather than it being out of the system. Systems must change because as they are installed in an environment the environment adapts to them and this adaptation naturally generates new/different system requirements. Furthermore, the system's environment is dynamic and constantly generates new requirements as a consequence of changes to the business, business goals and business policies. Unless the system is adapted to reflect these requirements, its facilities will become out-of-step with the facilities needed to support the business and, hence, it will become less useful.

5. Write a brief note on Risk Reduction Models.

Saved but needs to be edited. Ans Building a bridge or investing in a business involves a risk, as does developing a software product. Just as with other enterprises, the product may turn out to be harder to construct than expected or even infeasible or the market for the product may disappear. Below are the various models that address the issue of risk in software development:

1. The Prototyping Model Prototypes are used in many engineering disciplines. Although what constitutes a software or information systems prototype cannot be uniquely defined, there are three readily identifiable characteristics. The prototype should be able to: Be a temporary system Be designed rapidly Provide a tangible or visual expression of a proposed system.

The prototyping approach usually involves building a small version of the intended system prior to building the proposed complete system. This allows developers an opportunity to work out the kinks in the specification and design of the system before its full-scale development is attempted; the expectation is that this will significantly reduce the risk of development. The need for such risk reduction may derive from the novelty of the application or because the user interface design requires user experience and feedback based on the users live interaction with a tangible approximation of the desired product 2. The Spiral Model The most famous risk reduction strategy is Boehms Spiral Model, which relies heavily on prototyping but is also designed to allow incorporating other process models into its cycles. Each spiral development cycle is like a mini-life cycle, with its deliverables and assurance processes intended to minimize risk. The model is highly flexible and designed for customization.

The Spiral Model inherits the advantages of the existing process models that it incorporates, but tries to overcome their limitations by its persistent focus on development risk management. The spiral approach also relies on experience with risk assessment and the need for explicit process guidance in determining [the] objectives, constraints, and alternatives required for the next cycle of elaboration. 3. The Cleanroom Model The Cleanroom approach to software engineering was developed at IBM by Harlan Mills around 1982. It uses a team-oriented model that focuses on enforcing the use of theoretically sound engineering processes and practices. It has three foundations: incremental development under statistical quality control; software development based on mathematical principles; and software testing based on statistical principles. Its quality-control-driven philosophy is intended to improve the manageability and complete requirements lead to a significant reduction of risk. The approach is applicable not only to newly developed systems, but also to legacy environments by appropriately reengineering existing legacy components.

The software components are viewed as defining mathematical functions in which the function domain is the set of possible input histories and the function range is the set of all correct outputs. The functions are described using different kinds of box structures. In an object-oriented context, a so-called black box would correspond purely to the behavior of an object; a state box would correspond to the objects encapsulated state data; and a clear box would correspond to the objects methods.

6. What are the different stages of implementing a CMM?

Saved but needs to be edited. Ans The Capability Maturity Model (CMM) is a development model that was created after study of data collected from organizations that contracted with the U.S. Department of Defense, who funded the research. When the CMM is applied to an existing organization's software-development processes, it allows an effective approach toward improving them. Eventually it became clear that the model could be applied to other processes. Different stages of implementing a CMM are :

Ad-hoc / crises. Your organization has few common processes. The success of your projects depends on the strength and skills of your people. The organization provides little in a supporting environment to help make all projects successful. Most companies are at this level; although some companies say half-jokingly that they are at a 0 or even a -1 level.

Standard project management. Your organization has implemented standard project management processes, and you utilize these common processes on all projects. You are trying to establish a baseline foundation upon which to improve further in the future. Most companies that start down the CMMI path are trying to reach this level.

Standard software development. You are trying to achieve standardization in your development process similar to what you did for project management in level 2. This includes common and repeatable software development processes, deliverables, tools, etc.

Managed feedback. You collect metrics on all aspects of your project management and development processes. you have a repository of metrics and key learnings on historical projects that can be leveraged by new projects.

Optimizing / continuous improvement. you have a closed loop of process execution, measurement and continuous improvement. You continuously use measurement, feedback and creativity to optimize your processes.

7. Explain the round-trip problem solving approach.

Saved but needs to be edited.

Ans The software engineering process represents a round-trip framework for problem solving in a business context in several senses. The software engineering process is a problem-solving process entailing that software engineering should incorporate or utilize the problem-solving literature regardless of its interdisciplinary sources. The value of software engineering derives from its success in solving business and human problems. This entails establishing strong relationships between the software process and the business metrics used to evaluate business processes in general. The software engineering process is a round-trip approach. It has a bidirectional character, which frequently requires adopting forward and reverse engineering strategies to restructure and reengineer information systems. It uses feedback control loops to ensure that specifications are accurately maintained across multiple process phases; reflective quality assurance is a critical metric for the process in general. The nonterminating, continuing character of the software development process is necessary to respond to ongoing changes in customer requirements and environmental pressures.

8. What are the factors that effect inter-disciplinary ignorance?

The term ignorance refers to a lack of data or the presence of inaccurate data in a circumstance in which such a lack hinders the proper understanding and definition of business and human problems. Ignorance in this sense includes lack of knowledge about available information as well as about adequate or effective tools. This results in a problem-solving process that may have unreliable or insufficient inputs. Understanding the sources and varieties of ignorance can help reduce the failure rate in problem-solving processes. Just as in the case of domain knowledge, domain or process ignorance is also an interdisciplinary phenomenon; thus, overcoming this kind of ignorance requires an interdisciplinary response. Although a thorough grasp of a problem area and the solution domain results in success, ignorance masks or obscures the real situation and thus broadens the distance between actual problems and their appropriate solutions. The many sources of ignorance include unreliable sources of information; partial knowledge; lack of communication; and inter-organizational ignorance. Unreliable Sources of Information: This category includes inadequately accountable sources of information. Partial Knowledge: This refers to aspects of an issue that have not been revealed (so-called in-breadth ignorance) or information about a specific aspect of an issue that is left incomplete (so-called in-depth ignorance). This type of ignorance may even derive from a complacent or self-satisfied attitude what we do not know does not exist. Lack of Communication: Lack of communication is a major source of ignorance. Lack of communication originates in factors such as failure to contact the stakeholders in a business problem; not using effective communication techniques; or not being able to carry out an efficient communication process. The effects of a lack of communication can be summarized as follows: Ignorance of lack of sources

Extracontextual ignorance. Ignorance of lack of communication channels Differentiation ignorance Inter-organizational Ignorance: The value of knowledge stems from its usability and adaptability, not from its mere existence. To be valuable, information or data must add value to an organization and to its problem-solving processes. Otherwise, it is tantamount to a form of double ignorance in which people do not know what they know but assume that they do (or, they do not know that they do not know). This can make knowledge expensive if one is in possession of unused data, or make an organization a victim of knowledge utilization delays that result from a lack of awareness or ignorance of ignorance. Examples include Unprocessed data, unused data, untailored data, vague data, politically based ignorance, technically based ignorance, statistically based ignorance and Illusion-based ignorance.

9. Write a note on the contributions of the customer and the developer towards the development phase.
Saved but needs to be edited. Ans Contribution of the customer towards the development phase : It is a truism that, in a customer-focused economy, software engineering must also be customer driven. Some characteristics and techniques typical of a customer-driven software development environment are :

Customer-driven development is requirements intensive and features driven. Because customer needs are the highest priority, they must be carefully gathered, identified, specified, visualized, and internally prioritized among themselves. As a consequence, requirements engineering becomes the key strategic phase across the software engineering process. Customer-driven development is iterative in nature. Iterative development is essential because it allows extensive feedback and development response to the feedback. Customer-driven development aims to develop killer applications. The only way to survive in a highly competitive market is to develop winning applications not ordinary applications that merely pass the test of basic viability. Customer-driven development strongly values time to market. Time means opportunity, so applications must be engineered expeditiously enough to capture time-dependent marketing opportunities. Customer-driven development attempts to achieve multistakeholder satisfaction via win-win situations. Every software development activity involves many participants, each of whom has his or her goals and views of what constitutes value; therefore, the effective reconciliation of conflicts over system requirements becomes a key factor in assuring customer satisfaction. Customer-driven development focuses on quality in products and services. Quality assurance implies managing software processes in such a way that the developer and the customer are satisfied with the quality and consistency of the goods or services produced or provided. Customer-driven development views customers as partners not merely as buyers. In order to assure that customer expectations are met, customers should team up with developers at each phase of the software

development process. This can significantly minimize risk and reduce cycle time throughout the development process. Customer-driven development is customizable, personalized, and adaptable to individual needs and changes in needs. No two businesses or individuals are identical (demands and needs vary and evolve even across a single organization), so recognizing individual differences and organizational diversity is crucial to providing effective solutions. Security and privacy are concerns in any customer-driven solution. To earn customer trust, software engineers must design reliable systems that are less likely to be vulnerable to privacy invasions or security hackers. Cpntribution of developer in the development phase : A software developer is a person concerned with facets of the software development process. Their work includes researching, designing, developing, and testing software.[1] A software developer may take part in design, computer programming, or software project management. They may contribute to the overview of the project on the application level rather than component-level or individual programming tasks. Software developers are often still guided by lead programmers but the description also encompasses freelance software developers. Aspects of developer's job may include:

Software design Actual core implementation (programming which is often the most important portion of software development) Other required implementations (e.g. installation, configuration, customization, integration, data migration) Participation in software product definition, including business case or gap analysis Specification Requirements analysis Development and refinement of throw-away simulations or prototypes to confirm requirements Feasibility and costbenefit analysis, including the choice of application architecture and framework, leading to the budget and schedule for the project Authoring of documentation needed by users and implementation partners etc. Testing, including defining/supporting acceptance testing and gathering feedback from pre-release testers Participation in software release and post-release activities, including support for product launch evangelism (e.g. developing demonstrations and/or samples) and competitive analysis for subsequent product build/release cycles Maintenance