Explain System Design Process ?

The Systems Development Life Cycle (SDLC), or Software Development Life Cycle in systems engineering, information systems and software engineering, is the process of creating or altering systems, and the models and methodologies that people use to develop these systems. The concept generally refers to computer or information systems.

In software engineering the SDLC concept underpins many kinds of software development methodologies. These methodologies form the framework for planning and controlling the creation of an information system the software development process.

The System Development Life Cycle framework provides a sequence of activities for system designers and developers to follow. It consists of a set of steps or phases in which each phase of the SDLC uses the results of the previous one.

A Systems Development Life Cycle (SDLC) adheres to important phases that are essential for developers, such as planning, analysis, design, and implementation, and are explained in the section below. A number of system development life cycle (SDLC) models have been created: waterfall, fountain, spiral, build and fix, rapid prototyping, incremental, and synchronize and stabilize. The oldest of these, and the best known, is the waterfall model: a sequence of stages in which the output of each stage becomes the input for the next. These stages can be characterized and divided up in different ways, including the following:

• Project planning, feasibility study: Establishes a high-level view of the intended project and determines its goals.
• Systems analysis, requirements definition: Refines project goals into defined functions and operation of the intended application. Analyzes end-user information needs.
• Systems design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudocode and other documentation.
• Implementation: The real code is written here.
• Integration and testing: Brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability.
• Acceptance, installation, deployment: The final stage of initial development, where the software is put into production and runs actual business.
• Maintenance: What happens during the rest of the software's life: changes, correction, additions, moves to a different computing platform and more. This, the least glamorous and perhaps most important step of all, goes on seemingly forever.

What is the use of matrices ?Explain class oriented matrices .

Increasingly, object-oriented measurements are being used to evaluate and predict the quality of software . A growing body of empirical results supports the theoretical validity of these metrics. The validation of these metrics requires convincingly demonstrating that

(1) the metric measures what it purports to measure (for example, a coupling metric really measures coupling) and

(2) the metric is associated with an important external metric, such as reliability, maintainability and fault-proneness. Often these metrics have been used as an early indicator of these externally visible attributes, because the externally visible attributes could not be measures until too late in the software development process.

CLASS ORIENTED MATRICES

Lines of code and functional point metrics can be used for estimating object-oriented software projects. However, these metrics are not appropriate in the case of incremental software development as they do not provide adequate details for effort and schedule estimation. Thus, for object-oriented projects, different sets of metrics have been proposed. These are listed below.

Number of scenario scripts: Scenario scripts are a sequence of steps, which depict the interaction between the user and the application. A number of scenarios is directly related to application size and number of test cases that are developed to test the software, once it is developed. Note that scenario scripts are analogous to use-cases.

Number of key classes: Key classes are independent components, which are defined in object -oriented analysis. As key classes form the core of the problem domain, they indicate the effort required to develop software and the amount of 'reuse' feature to be applied during the development process.

Number of support classes: Classes, which are required to implement the system but are indirectly related to the problem domain, are known as support classes. For example, user interface classes and computation class are support classes. It is possible to develop a support class for each key class. Like key classes, support classes indicate the effort required to develop software and the amount of 'reuse' feature to be applied during the development process.

Average number of support classes per key class: Key classes are defined early in the software project while support classes are defined throughout the project. The estimation process is simplified if the average number of support classes per key class is already known.

Number of subsystems: A collection of classes that supports a function visible to the user is known as a subsystem. Identifying subsystems makes it easier to prepare a reasonable schedule in which work on subsystems is divided among project members.

The afore-mentioned metrics are collected along with other project metrics like effort used, errors and defects detected, and so on. After an organization completes a number of projects, a database is developed, which shows the relationship between object-oriented measure and project measure. This relationship provides metrics that help in project estimation.

Explain Component Based Software Engineering ?

ANSWER: Software components are units of software designed to interact with other independently developed components, and to be assembled by third parties into applications. Software component engineering focuses on the packaging of software into independent units to allow maximum reusability.

Component-based software development (CBD) is an evolution of object oriented software development (OOD). While both share the goal of software reusability, OOD is an implementation methodology, while CBD is an interface methodology. In CBD the emphasis is on standardizing the interfaces between components, with no restrictions on how the implementation is accomplished. CBD therefore is closely related to module design in separating interface and implementation..

In OOD, code reuse is accomplished through inheritance of implementation code. While OO languages also generally allow separation of implementation and interface, in practice the desire for code reuse often complicates data typing, and inheritance breaks data encapsulation (Snyder86). Partly for these reasons and partly due to the extra level of effort to prevent unnecessary dependencies, class hierarchies tend to be reused only within an application. Of course, class libraries as well as procedural libraries designed to be incorporated into larger applications are successful examples of software reuse.

Components require a deployment environment that Szyperski calls a component world or component environment. The services that a component needs from its environment are called its context dependencies. The mechanisms by which components interact are sometimes called wiring standards, and are one of the most important specifications of a component environment. There are currently three major component environments: The Object Management Group’s (OMG) CORBA, Microsoft’s COM, and Sun’s JavaBeans.

CORBA is an interface standard for distributed objects which may be implemented in different languages and running on different platforms. An object is defined with an Interface Description Language (IDL), and language and platform specific bindings must be created by CORBA vendors.

COM is a binary standard that defines interfaces between components. It grew out of Microsoft’s highly successful Visual Basic controls. A COM component can be implemented in any language, although is most often created in Visual Basic or C++, since Microsoft provides tools for those languages. COM is supported for MS Windows. MacOS, and by third parties for other platforms. COM supports interface inheritance but not implementation inheritance, and allows components to be nested inside of one another. DCOM is an extension of COM to distributed components. COM+ is an object-oriented version of COM for components within a single process.

JavaBeans is a set of conventions for Java to support component-based software development. The support for these conventions is embedded in the Java language and supporting class libraries, so JavaBeans is a Java-only component framework. However, using the Java Native Interface API, Java classes can wrap components built in other languages, can become COM components, and can be CORBA components as well.

A component describes itself through its interface, which can be thought of as a contract with whoever uses it. The contract has two parts: the syntax specifies the data types of the interface method’s arguments, which can be enforced automatically at compile or run time. The contract semantics describe the behaviour of the component, and can only be understood by humans, and so typically is represented by the documentation that the component developer provides. Because semantics are always context specific, the standardization of component behaviour is necessarily specific to an application domain, and are called domain standards. The OMG has created several "domain task forces" to create domain standards for business, manufacturing, electronic commerce, telecommunications, finance, and medicine. Both the Java and OLE communities also have domain specific efforts.

The combination of domain standards and supporting implementation classes and components that facilitate independent component development is called a component application framework, the most familiar example being GUI application builders.

 A component framework must specify both wiring and domain standards for the components it provides, that is, both syntactic and semantic descriptions of its interfaces. In practice, a component framework is an implementation of a domain standard and so both simultaneously evolve out of each other.

ADVANCE SOFTWARE ENGINEERING MSC IT & CA SEM-3 QUESTION BANK(as par syallbus of saurashtra university)

Software Engineering MSCIT Sem-3

1. Explain object-oriented concepts with example
2. Explain object-oriented s/w projects management in brief.
3. Explain object-oriented paradigm with figure.
4. Explain generic components of object-oriented analysis modal.
5. Explain object-relationship modal with appropriate example.
6. Write brief note on object-behavior modal.
7. Explain domain analysis with figure
8. Explain CRC modal index card or Explain OOA process and give brief description of CRC modal index card.
9. Explain OOA process.
10.    Briefly define  a)operation  b)message  c)  method  d) services  e)class 
11.    Briefly explain how to identify classes and objects while developing oo model.
12.    Briefly explain Booch and Rumbaugh method for OOA.
13.    Explain the process of translating an OOA model in OOD model with diagram.
14.    What do you mean by system design process? Explain activities involved in it.
15.    Write short note on object-design process.
16.    Write short note on Design Patterns,
17.    Discuss design of object-oriented system with appropriate example.
18.    Give the name of testing method which are applicable at class level and explain it in details.
19.    Write brief note on testing object-oriented design and object-oriented analysis model.
20.    What do you mean by testing context to object oriented? Explain testing strategies in context to object oriented system development.
21.    Which is the impact of OOP on testing?
22.    Explain fault based testing.
23.    Explain interclass test case design.
24.    Define the objectives of OOT correctness and consistency.
25.    Explain the characteristics of OOM.
26.    What are the metrics for OOD model.
27.    Explain metrics of object-oriented projects.
28.    Briefly explain CK metrics suite proposed by chidamber and kemerer.
29.    Provide detail view of class oriented metrics
30.    Describe following terms
31. Class size   b.  NOO    c. NOA   d. SI
32.    Specify MOOD metrics suite.
33.    Describe operation-oriented metrics.
34.    Explain metrics for object-oriented testing.
35.    What do you meant by cleanroom SE? describe common approach and its strategy with figure.
36.    What is BSS in cleanroom SE? describe types of boxes used in functional specification of cleanroom approach.
37.    Write brief note on cleanroom SE approach.
38.    Explain clean-room testing.
39.    Explain design refinement and verification.
40.    Describe statistical use testing and what its core utility?
41.    Write short note on component based software engineering process.
42.    Describe component qualification and component adaption.
43.    What do you mean by CBSE? Explain different set of s/w engineering activities involved in CBSE.
44.    Briefly explain component composition activity involved in CBSE.
45.    Explain Domain Engineering with its identification and reusable components.
46.    Write short note on classifying and retrieving components.

USE SINGLE QUERY FOR UPDATE STATUS OF ANY ENUM

Create table feedback (

fid int(3),name varchar2(30),

email varchar(20),subject varchar(30),

satatus enum('0','1')); 

---

UPDATE feedback SET status =  
CASE
  WHEN  1 THEN 0
  WHEN 0 THEN 1
END
WHERE fid = 3;

---

SELECT CASE is_status
      WHEN 1 THEN 'Replied'
      WHEN 0 THEN 'Not Replied'
      END AS 'fstatus'
FROM feedback;