Master of Computer Application (MCA) Semester 3

Software Engineering
Assignment Set 1

Que: 1. Explain Iterative Development Model in detail.

Ans:

Iterative Model

The iterative enhance model counters the third limitation of the waterfall model and tires to combine a benefit of both prototyping and the waterfall mode. The basic idea is that the software should be developed in increments, each increment adding some functional capability to the system until the full system is implemented. At each step, extensions and design modifications can be made. An advantage of this approach is that it can result in better testing because testing each increment is likely to be easier than testing the entire system as in the waterfall model. The increment models provide feedback to the client i.e., useful for determining the final requirements of the system. In the first step of this model, a simple initial implementation is done for a subset of the overall problem. This subset is one that contains some of the key aspects of the problem that are easy to understand and implement and which form a useful and usable system. A project control list is created that contains, in order, all the tasks that must be performed to obtain the final implementation this project control list gives a idea of how far the project is at any given step from the final system.

Each step consists of removing the next task from the list, designing the implementation for the selected task, coding and testing the implementation, performing an analysis of the partial system obtained after this step, and updating the list as a result on the analysis. These three phases are called the design phase, implementation phase and analysis phase. The process is integrated until the project control list is empty, at which time the final implementation of the system will be available. The iterative enhancement process model is shown in below diagram:
Software Engineering MC0071 Roll No. 521150974

The project control list guiders the iteration steps and keeps track of all tasks that must be done. Based on the analysis, one of the tasks in the list can include redesign of defective components or redesign of the entire system. Redesign of the system will occur only in the initial steps. In the later steps, the design would have stabilized and there is less chance of redesign. Each entry in the list is a task that should be performed in one step of the iterative enhancement process and should be completely understood. Selecting tasks in this manner will minimize the chance of error and reduce the redesign work. The design and implementation phases of each step can be performed in a top-down manner or by using some other technique. One effective use of this type of model is for product development, in which the developers themselves provide the specifications and therefore have a lot of control on what specifications go in the system and what stay out. In a customized software development, where the client has to essentially provide and approve the specifications, it is not always clear how this process can be applied. Another practical problem with this type of development project comes in generating the business contract-how will the cost of additional features be determined and negotiated, particularly because the client organization is likely to e tied to the original vendor who developed the first version. Overall, in these types of projects, this process model can be useful if the "core" Of the applications to be developed is well understood and the "increments" can be easily defined and negotiated. In client-oriented project, this process has the major advantage that the client's organization does not have to pay for the entire software together, it can get the main part of the software developed and perform cost benefit analysis for it before enhancing the software with more capabilities.

Software Engineering MC0071

Roll No. 521150974

Que: 2. Describe the Object Interface Design. Ans: Object Interface design is concerned with specifying the detail of the object interfaces. This means defining the types of the object attributes and the signatures and the semantics of the object operations. If an object-oriented programming language is being used for implementation, it is natural to use it to express the interface design. Designers should avoid interfaces representation information in their interface design. Rather, the representation should be hidden and object operations provided to access and update the data. If the representation is hidden, it can be changed without affecting the objects that use these attributes. This leads to a design which is inherently more maintainable. For example, an array representation of a stack may be changed to a list representation without affecting other objects, which use the stack. Design evolution An important advantage of an object-oriented approach to design is that it simplifies the problem of making changes to the design. The reason for this is that object state representation does not influence the design. Changing the internal details of an object is unlikely to affect any other system objects. Furthermore, because objects are loosely coupled, it is usually straightforward to introduce new objects without significant effects on the rest of the system. To illustrate the robustness of the object-oriented approach, assume that pollution-monitoring capabilities are to be added to each weather station. This involves adding an air quality meter to compute the amount of various pollutants in the atmosphere. The pollution readings are transmitted at the same time as the weather data. To modify the design, the following changes must be made: Figure below shows weather station and the new objects to the system. The abbreviation NO in Air quality stands for nitrous oxide.

Software Engineering MC0071

Roll No. 521150974

New objects to support pollution monitoring (1) An object Air quality should be introduced as part of Weather station at the same level as Weather data. (2) An operation Transmit pollution data should be added to Weather station to send the pollution information to the central computer. The weather station control software must be modified so that pollution readings are automatically collected when the system is switched on. (3) Objects representing the types of pollution, which can be monitored, should be added. Levels of nitrous oxide, smoke and benzene can be measured. (4) A hardware control object Air quality meter should be added as a sub-object to Air quality. This has attributes representing each of the types of measurement, which can be made. The addition of pollution data collection does not affect weather data collection in any way. Data representations are encapsulated in objects so they are not affected by the additions to the design.

Software Engineering MC0071

Roll No. 521150974

Function oriented design A function-oriented design strategy relies on decomposing the system into a set of interacting functions with a centralized system state shared by these functions as shown in figure below. Functions may also maintain local state information but only for the duration of their execution.

A function-oriented view of design

Function-oriented has been practiced informally since programming began. Programs were decomposed into subroutines, which were functional in nature. In the late 1960s and early 1970s several books were published which described top-down functional design. They specifically proposed this as a structured design strategy. These led to the development of many design methods based on functional decomposition. Function-oriented design conceals the details of an algorithm in a function but system state information is not hidden. This can cause problems because a function can change the state in a way, which other functions do not expect. Changes to a function and the way in which it uses the system state may cause unanticipated changes in the behavior of other functions. A functional approach to design is therefore most likely to be successful when the amount of system state information is minimized and information sharing is explicit. Systems whose responses depend on a single stimulus or input and which are not affected by input histories are naturally function-oriented. Many transaction-processing systems and business data-processing systems fall into this class. In
Software Engineering MC0071 Roll No. 521150974

essence, they are concerned with record processing where the processing of one record is not dependent on any previous processing.

Software Engineering MC0071

Roll No. 521150974

Que: 3. Explain why it is important to describe software designs. Ans: Importance of describing Software Design: There are many aspects to software design, and many varying methodologies. When attempting to produce any piece of software (and particularly a large and complex one) it is vital to consider several areas. Many people only look at a small component of this when "designing" their programs. Why? Either they are not aware the other components require design, or they cannot be bothered to do it.

The main components in software include: - required functionality - additional (optional) functionality - user interface - internal data structures - external data structures - program/object structure

Without applying design principles to these and often other areas, you end up with a lot of common software problems: scope creep, poor functionality, unwieldy or difficult to use UI, poor performance, over-sized data files, overly complex processing, impossible to maintain code.

"Design" of required and optional functionality is traditionally the Specification phase of a project/program. The remaining areas should occur during the Design Phase of a project and be revised during Implementation (or post-Prototype). The exact timing and processes will depend on the methodology being used, but all should occur.

In the early stages of a project or program, the "functionality design" or specifications need to occur. Without specifications, the development is unguided. It is difficult to know when the program is complete - and impossible to accurately measure progress. It is also difficult for a programmer to be motivated when the task is not well defined.

Software Engineering MC0071

Roll No. 521150974

It is just as important to perform this stage when writing software for yourself as it is when writing for a client.

User interface design is one of the most considered aspects of software design. Everybody is aware that without a usable interface, no software product will be widely used. It is important to plan the user interface, and discuss or demonstrate it to the end users - something that you may consider appropriate may not fit well with the way they expect your product to work.

Even if coding for yourself; plan what information needs to be displayed and entered, how it relates to other information, and how to efficiently present that information.

Without performing UI design (whether graphical or command-line), a program will seem unprofessional, and most likely will have over-crowded and difficult to use screens.

Program design refers to the structure of the program. The methods here will vary greatly (particularly for OO vs procedural languages). A well designed program will be easier to implement; easier to distribute; and easier to maintain.

Internal and external data structures refer to how the data used by your program is held and handled within the program, or when stored for later use, respectively. Well designed data structures make it easier to handle the information within your program. More importantly, they make your program more flexible and easier to add or change functionality. They can also have a huge impact on the performance of your completed application.

Using design patterns may help solve certain problems, but if used improperly, they add complexity where not required. However, when used correctly and as part of the complete process, design patterns can save a lot of work in the program and data structure design areas.

Many tools, techniques and methodologies exist to aid with design - and not all are appropriate for all situations. However, the design of a product is of vital importance for it to be complete and usable, and robust.
Software Engineering MC0071 Roll No. 521150974

Software Engineering MC0071

Roll No. 521150974

Que: 4. Write an overview on the Rational Unified Process. Ans: The Rational Unified Process or RUP product is a software engineering process. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end users within a predictable schedule and budget. UML has become a widely accepted, standard notation for object-oriented architecture and design. The widespread acceptance of UML allows developers to perform system design and provide design documentation in a consistent and familiar manner. The standardization reduces the need for developers to learn new notational techniques and improves communication among the development team and stakeholders. The Rational Rose software suite is a GUI or visual modeling tool available from Rational Software that lets developers model a problem, its design, implementation, and indeed the entire development process, all the way through testing and configuration management, using the UML notation. The Rational suite is arguably one of the most important demonstrations of an approach that reflects Osterweils famous aphorism that software processes are software, too (Osterweil 1987). This development product is widely used, especially for e-business applications. Krutchen (2003) provides an excel-lent overview of the approach and its software engineering motivations. Jacobson, Booch, and Rambaugh (1999) give a detailed description of the Rational Rose product and its associated development process. Tool mentors are provided with the actual product that can be used as a sort of electronic coach on software engineering (Krutchen 2003). For a simple but useful introductory tutorial about how to use at least a part of the Rational Rose CASE tool, with detailed discussions and illustrations of the Rose tools and windows for use case diagrams and class diagrams, see cse.dmu.ac.uk/Modules. Refer to Booch, Jacobson, and Rumbaugh (1998) for UML and Larman (2001) for UML object-based design and analysis. The Web site, http://www.agilemodeling.com, provides useful guidelines on UML diagramming tools. The rational unified process (RUP) is built around visual software support for what its designers believe are the essential best practices for effective software development, namely:

Software Engineering MC0071

Roll No. 521150974

 Iterative development. The iterative, Boehm-style, spiral approach is intended to mitigate development risk by using a combination of early implementation and requirements testing and modification in order to expose requirements errors early. So-called requirements management. The management requirements objective specifically addresses evaluating and tracking the effect of changes to the requirements. Use of component-based software architectures. Component-based development allows the use (or reuse) of commercially available system components and ultimately continuous (re)development, but involves the complexities of gluing the components together. This is also highly consistent with the fundamental principle of separation of concerns. Use of tools that support visual design of the system, continuous verification, and change management. Intelligently designed visual modeling tools help manage and share development artifacts, allow differing levels of design resolution, and support classic UML artifacts such as cases and scenarios. Computer-supported testing tools simplify verification. Automated coordination tools organize the workflow of system requirements, a coordination that involves a complex network of development activities and artifacts executed by multiple development teams at possibly many sites, and coordinate the process iterations and product releases. The RUP constitutes a complete framework for software development. The elements of the RUP (not of the problem being modeled) are the workers who implement the development, each working on some cohesive set of development activities and responsible for creating specific development artifacts. A worker is like a role a member plays and the worker can play many roles (wear many hats) during the development. For example, a designer is a worker and the artifact that the designer creates may be a class definition. An artifact supplied to a customer as part of the product is a deliverable. The artifacts are maintained in the Rational Rose tools, not as separate paper documents. A workflow is defined as a meaningful sequence of activities that produce some valuable result (Krutchen 2003). The development process has nine core workflows: business modeling; requirements; analysis and design; implementation; test; deployment; configuration and change management; project management; and environment. Other RUP elements, such as tool mentors, simplify training in the use of the Rational Rose system. These core workflows are spread out over the four phases of development: The inception phase defines the vision of the actual user end-product and the scope of the project.
Software Engineering MC0071 Roll No. 521150974

 The elaboration phase plans activities and specifies the architecture. The construction phase builds the product, modifying the vision and the plan as it proceeds. The transition phase transitions the product to the user (delivery, training, support, maintenance). In a typical two-year project, the inception and transition might take a total of five months, with a year required for the construction phase and the rest of the time for elaboration. It is important to remember that the development process is iterative, so the core workflows are repeatedly executed during each iterative visitation to a phase. Although particular workflows will predominate during a particular type of phase (such as the planning and requirements workflows during inception), they will also be executed during the other phases. For example, the implementation workflow will peak during construction, but it is also a workflow during elaboration and transition. The goals and activities for each phase will be examined in some detail. The purpose of the inception phase is achieving concurrence among all stakeholders on the objectives for the project. This includes the project boundary and its acceptance criteria. Especially important is identifying the essential use cases of the system, which are defined as the primary scenarios of behavior that will drive the systems functionality. Based on the usual spiral model expectation, the developers must also identify a candidate or potential architecture as well as demonstrate its feasibility on the most important use cases. Finally, cost estimation, planning, and risk estimation must be done. Artifacts produced during this phase include the vision statement for the product; the business case for development; a preliminary description of the basic use cases; business criteria for success such as revenues expected from the product; the plan; and an overall risk assessment with risks rated by likelihood and impact. A throw-away prototype may be developed for demonstration purposes but not for architectural purposes. The following elaboration phase ensures that the architecture, requirements, and plans are stable enough, and the risks are sufficiently mitigated, that [one] can reliably determine the costs and schedule for the project. The outcomes for this phase include an 80 percent complete use case model, nonfunctional performance requirements, and an executable architectural prototype. The components of the architecture must be understood in sufficient detail to allow a decision to make, buy, or reuse components, and to estimate the schedule and costs with a reasonable degree of confidence. Krutchen observes that a robust architecture and an understandable plan are highly correlated, so one of the
Software Engineering MC0071 Roll No. 521150974

critical qualities of the architecture is its ease of construction. Prototyping entails integrating the selected architectural components and testing them against the primary use case scenarios. The construction phase leads to a product that is ready to be deployed to the users. The transition phase deploys a usable subset of the system at an acceptable quality to the users, including beta testing of the product, possible parallel operation with a legacy system that is being replaced, and software staff and user training. Software architecture is concerned with the major elements of the design, including their structure, organization, and interfaces. The representation of architecture traditionally uses multiple views for example, in the architectural plans for a building: floor plans, electrical layout, plumbing, elevations, etc. (Krutchen 2003). The same holds for RUP architectural plans, which include the logical view of the system, an organized view of the system functionality, and concurrency issues. RUP recommends a so-called 4 + 1 view of architecture. The logical view addresses functional requirements. The implementation view addresses the software module organization and issues such as reuse and off-the-shelf components. The process view addresses concurrency, response time, scalability, etc. The deployment view maps the components to the platforms. The use-case view is initially used to define and design the architecture, then subsequently to validate the other views. Finally, the architecture is demonstrated by building it. This prototype is the most important architectural artifact; the final system evolves from this prototype. The RUP is driven by use cases that are used to understand a problem in a way accessible to developers and users. A use case may be defined as a sequence of actions a system performs that yields an observable result that is of value to a particular actor (Krutchen 2003); an actor is any person or external system that interacts with the proposed system. Put another way, a use case accomplishes an actors goal. The requirement that the action be useful to the end -user establishes an appropriate level of granularity for the requirements so that they are understandable and meaningful to the users.

Software Engineering MC0071

Roll No. 521150974

Que: 5. Describe the Capability Maturity Model. Ans: The Capability Maturity Model A set of quality assurance standards was originally developed by the International Standards Organization (ISO) under the designation ISO 9000 in 1987 and revised subsequently in 1994 and 2000. The purpose of these standards was to define the quality system that a business or industrial organization would need to follow to ensure the consistency and quality of its products. A procedure for certifying that a business met these standards was also established so that potential customers would have some confidence in the organizations processes and products. The Capa bility Maturity Model developed by the Software Engineering Institute (SEI) at CarnegieMellon University is a model for identifying the organizational processes required to ensure software process quality. The Capability Maturity Model (CMM) is a multistage, process definition model intended to characterize and guide the engineering excellence or maturity of an organizations software development processes. The model prescribes practices for planning, engineering, and managing software development and maintenance and addresses the usual goals of organizational system engineering processes: namely, quality improvement, risk reduction, cost reduction, predictable process, and statistical quality control (Oshana & Linger 1999). However, the model is not merely a program for how to develop software in a professional, engineering-based manner; it prescribes an evolutionary improvement path from an ad hoc, immature process to a mature, disciplined process (Oshana & Linger 1999). Walnau, Hissam, and Seacord (2002) observe that the ISO and CMM process standards established the co ntext for improving the practice of software development by identifying roles and behaviors that define a software factory.

Software Engineering MC0071

Roll No. 521150974

The CMM identifies five levels of software development maturity in an organization: At level 1, the organizations software development follows no formal development process. The process maturity is said to be at level 2 if software management controls have been introduced and some software process is followed. A decisive feature of this level is that the organizations process is supposed to be such that it can repeat the level of performance that it achieved on similar successful past projects. This is related to a central purpose of the CMM: namely, to improve the predictability of the development process significantly. The major technical requirement at level 2 is incorporation of configuration management into the process. Configuration management (or change management, as it is sometimes called) refers to the processes used to keep track of the changes made to the development product (including all the intermediate deliverables) and the multifarious impacts of these changes. These impacts range from the recognition of development problems; identification of the need for changes; alteration of previous work; verification that agreed upon modifications have corrected the problem and that corrections have not had a negative impact on other parts of the system; etc. An organization is said to be at level 3 if the development process is standard and consistent. The project management practices of the organization are supposed to have been formally agreed on, defined, and codified at this stage of process maturity. Organizations at level 4 are presumed to have put into place qualitative and quantitative measures of organizational process. These process metrics are intended to monitor development and to signal trouble and indicate where and how a development is going wrong when problems occur. Organizations at maturity level 5 are assumed to have established mechanisms designed to ensure continuous process improvement and optimization. The metric feedbacks at this stage are not just applied to recognize and control problems with the current project as they were in level-4 organizations. They are intended to identify possible root causes in the process that have allowed the problems to occur and to guide the evolution of the process so as to prevent the recurrence of such problems in future projects, such as through the introduction of appropriate new technologies and tools. The higher the CMM maturity level is, the more disciplined, stable, and well-defined the development process is expected to be and the environment is assumed to make more u se of automated tools and
Software Engineering MC0071 Roll No. 521150974

the experience gained from many past successes (Zhiying 2003). The staged character of the model lets organizations progress up the maturity ladder by setting process targets for the organization. Each advance reflects a further degree of stabilization of an organizations development process, with each level institutionalizing a different aspect of the process (Oshana & Linger 1999). Each CMM level has associated key process areas (KPA) that correspond to activities that must be formalized to attain that level. For example, the KPAs at level 2 include configuration management, quality assurance, project planning and tracking, and effective management of subcontracted software. The KPAs at level 3 include intergroup communication, training, process definition, product engineering, and integrated software management. Quantitative process management and development quality define the required KPAs at level 4. Level 5 institutionalizes process and technology change management and optimizes defect prevention. The CMM model is not without its critics. For example, Hamlet and Maybee (2001) object to its overemphasis on managerial supervision as opposed to technical focus. They observe that agreement on the relation between the goodness of a process and the goodness of the product is by no means universal. They present an interesting critique of CMM from the point of view of the so-called process versus product controversy. The issue is to what extent software engineers should focus their efforts on the design of the software product being developed as opposed to the characteristics of the software process used to develop that product. The usual engineering approach has been to focus on the product, using relatively straightforward processes, such as the standard practice embodied in the Waterfall Model, adapted to help organize the work on developing the product. A key point of dispute is that no one has really demonstrated whether a good process leads to a good product. Indeed, good products have been developed with little process used, and poor products have been developed under the guidance of a lot of purportedly good processes. Furthermore, adopting complex managerial processes to oversee development may distract from the underlying objective of developing a superior product.

Software Engineering MC0071

Roll No. 521150974

Que: 6. Explain the round-trip problem solving approach. Ans: Round-Trip Problem Solving Approach 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 non-terminating, continuing character of the software development process is necessary to respond to ongoing changes in customer requirements and environmental pressures.

Software Engineering MC0071

Roll No. 521150974

Master of Computer Application (MCA) Semester 3

Software Engineering
Assignment Set 2

Que: 1. Describe the following with respect to Software Design: a. The design process b. Design Methods c. Design description d. Design strategies. Ans:

The design process

A general model of a software design is a directed graph. The target of the design process is the creation of such a graph without inconsistencies. Nodes in this graph represent entities in the design entities such as process function or types. The link represents relation between these design entities such as calls, uses and so on. Software designers do not arrive at a finished design graph immediately but develop the design iteratively through a number of different versions. The design process involves adding formality and detail as the design is developed with constant backtracking to correct earlier, less formal, designs. The starting point is an informal design, which is refined by adding information to make it consistent and complete as shown in figure below.

Software Engineering MC0071

Roll No. 521150974

The progression from an informal to a detailed design Figure shows a general model of the design process suggests that the stages of the design process are sequential. In fact, design process activities proceed in parallel. However, the activities shown are all part of the design process for large software systems. These design activities are: (1) Architectural designs the sub-systems making up the system and their relationships are identified and documented. (2) Abstract specification for each sub-system, an abstract specification of the services it provides and the constraints under which it must operate is produced. (3) Interface design for each sub-system, its interface with other sub-systems is designed and documented. This interface specification must be unambiguous as it allows the sub-system to be used without knowledge of the sub-system operation. (4) Component design Services are allocated to different components and the interfaces of these components are designed. (5) Data structure design the data structures used in the system implementation is designed in detail and specified. (6) Algorithm design the algorithms used to provide services are designed in detail and specified.
Requirement Specification

Architectur al Design

Abstract Specificat ion

Interface Design

Compone nt Design

Data Structure Design

Algorithm Design

System Architecture

Software Specification

Interface Specification

Component Specification

Structure Specification

Algorithm Specification

A general model of the design process This process is repeated for each sub-system until the components identified can be mapped directly into programming language components such as packages, procedures or functions.
Software Engineering MC0071 Roll No. 521150974

Design Methods
A more methodical approach to software design is purposed by structured methods, which are sets of notations and guidelines for software design. Budgen (1993) describes some of the most commonly used methods such as structured design, structured systems analysis, Jackson System Development and various approaches to object-oriented design. The use of structured methods involves producing large amounts of diagrammatic design documentation. CASE tools have been developed to support particular methods. Structured methods have been applied successfully in many large projects. They can deliver significant cost reductions because they use standard notations and ensure that standard design documentation is produced. A mathematical method (such as the method for long division) is a strategy that will always lead to the same result irrespective of who applies the method. The term structured methods suggests, therefore, that designers should normally generate similar designs from the same specification. A structured method includes a set of activities, notations, report formats, rules and design guidelines. So structured methods often support some of the following models of a system: (1) A data-flow model where the system is modeled using the data transformations, which take place as it, is processed. (2) An entity-relation model, which is used to describe the logical data, structures being used. (3) A structural model where the system components and their interactions are documented. (4) If the method is object-oriented it will include an inheritance model of the system, a model of how objects are composed of other objects and, usually, an object-use model which shows how objects are used by other objects. Particular method supplement these with other system models such as state transition diagrams, entity life histories that show how each entity is transformed as it is processed and so on. Most methods suggest a centralized repository for system information or a data dictionary should be used. No one method is better or worse than other methods: the success or otherwise of methods often depends on their suitability for an application domain.
Software Engineering MC0071 Roll No. 521150974

Design description
A software design is a model system that has many participating entities and relationships. This design is used in a number of different ways. It acts as a basis for detailed implementation; it serves as a communication medium between the designers of sub-systems; it provides information to system maintainers about the original intentions of the system designers, and so on. Designs are documented in a set of design documents that describes the design for programmers and other designers. There are three main types of notation used in design documents: (1) Graphical notations: These are used to display the relationships between the components making up the design and to relate the design to the real-world system is modeling. A graphical view of a design is an abstract view. It is most useful for giving an overall picture of the system. (2) Program description languages these languages (PDLs) use control and structuring constructs based on programming language constructs but also allow explanatory text and (sometimes) additional types of statement to be used. These allow the intention of the designer to be expressed rather than the details of how the design is to be implemented. (3) Informal text much of the information that is associated with a design cannot be expressed formally. Information about design rationale or non-functional considerations may be expressed using natural language text. All of these different notations may be used in describing a system design.

Design strategies
The most commonly used software design strategy involved decomposing the design into functional components with system state information held in a shared data area. Since from late 1980s that this alternative, object oriented design has been widely adopted. Two design strategies are summarized as follows:

Software Engineering MC0071

Roll No. 521150974

(1) Functional design: The system is designed from a functional viewpoint, starting with a high-level view and progressively refining this into a more detailed design. The System State is centralized and shared between the functions operating on that state. Methods such as Jackson Structured Programming and the Warnier-Orr method are techniques of functional decomposition where the structure of the data is used to determine the functional structure used to process that data. (2) Object-oriented design: The system is viewed as a collection of objects rather than as functions. Object-oriented design is based on the idea of information hiding and has been described by Meyer, Booch, and Jacobsen and many others. JSD is a design method that falls somewhere between functionoriented and object-oriented design. In an object-oriented design, the System State is decentralized and each object manages its own state information. Objects have a set of attributes defining their state and operations, which act on these attributes. Objects are usually members of an object class whose definition defines attributes and operations of class members. These may be inherited from one or more super-classes so that a class definition need only set out the differences between that class and its super-classes. Objects communicated by exchanging messages; an object calling a procedure associated with another object achieve most object communication. There is no best design strategy, which is suitable for all projects and all types of application. Functional and object-oriented approaches are complementary rather than opposing techniques. Software engineers select the most appropriate approach for each stage in the design process. In fact, large software systems are complex entities that different approaches might be used in the design of different parts of the system. An object-oriented approach to software design seems to be natural at the highest and lowest levels of system design. Using different approaches to design may require the designer to convert his or her design from one model to another. Many designers are not trained in multiple approaches so prefer to use either object-oriented or functional design.

Software Engineering MC0071

Roll No. 521150974

Que: 2. Describe the following with respect to Software Testing: a. Control Structure Testing b. Black Box Testing c. Boundary Value Analysis d. Testing GUIs e. Testing Documentation and Help Facilities Ans: Control Structure Testing The basis path testing technique described in Section 17.4 is one of a number of techniques for control structure testing. Although basis path testing is simple and highly effective, it is not sufficient in itself. in this section, other variations on control structure testing are discussed. These broaden testing coverage and improve quality of white-box testing. 1. Condition Testing 2. Data Flow Testing 3. Loop Testing

Black-Box Testing Black-box testing, also called behavioral testing, focuses on the functional requirements of the software. That is, black-box testing enables the software engineer to derive sets of input conditions that will fully exercise all functional requirements for a program. Black-box testing is not an alternative to white-box techniques. Rather, it is a complementary approach that is likely to uncover a different class of errors than white-box methods. Black-box testing attempts to find errors in the following categories: (1) incorrect or missing functions, (2) interface errors, (3) errors in data structures or external data base access, (4) behavior or performance errors, and (5) initialization and termination errors.
Software Engineering MC0071 Roll No. 521150974

Unlike white-box testing, which is performed early in the testing process, black- box testing tends to be applied during later stages of testing. Because black-box testing purposely disregards control structure, attention is focused on the information domain. Tests are designed to answer the following questions: How is functional validity tested? How is system behavior and performance tested? What classes of input will make good test cases? Is the system particularly sensitive to certain input values? How are the boundaries of a data class isolated? What data rates and data volume can the system tolerate? What effect will specific combinations of data have on system operation? By applying black-box techniques, we derive a set of test cases that satisfy the following criteria: (1) test cases that reduce, by a count that is greater than one, the number of additional test cases that must be designed to achieve reasonable testing and (2) test cases that tell us something about the presence or absence of classes of errors, rather than an error associated only with the specific test at hand.

Boundary Value Analysis For reasons that are not completely clear, a greater number of errors tends to occur at the boundaries of the input domain rather than in the "center." It is for this reason that boundary value analysis (BVA) has been developed as a testing technique. Boundary value analysis leads to a selection of test cases that exercise bounding values. Boundary value analysis is a test case design technique that complements equivalence partitioning. Rather than selecting any element of an equivalence class, BVA leads to the selection of test cases at the "edges of the class. Rather than focusing solely on input conditions, BVA derives test cases from the output domain as well. Guidelines for BVA are similar in many respects to those provided for equivalence partitioning:
Software Engineering MC0071 Roll No. 521150974

1. If an input condition specifies a range, bounded by values a and b, test cases should be designed with values a and b and just above and just below a and b. 2. If an input condition specifies a number of values, test cases should be developed that exercise the minimum and maximum numbers. Values just above and below minimum and maximum are also tested. 3. Apply guidelines 1 and 2 to output conditions. For example, assume that a temperature vs. pressure table is required as output from an engineering analysis program. Test cases should be designed to create an output report that produces the maximum (and minimum) allowable number of table entries. 4. If internal program data structures have prescribed boundaries (e.g., an array has a defined limit of 100 entries), be certain to design a test case to exercise the data structure at its boundary. Most software engineers intuitively perform BVA to some degree. By applying these guidelines, boundary testing will be more complete, thereby having a higher likelihood for error detection.

Testing GUIs Graphical user interfaces (GUIs) present interesting challenges for software engineers. Because of reusable components provided as part of GUI development environments, the creation of the user interface has become less time consuming and more precise. But, at the same time, the complexity of GUIs has grown, leading to more difficulty in the design and execution of test cases. Because many modern GUIs have the same look and feel, a series of standard tests can be derived. Finite state modeling graphs may be used to derive a series of tests that address specific data and program objects that are relevant to the GUI. Due to the large number of permutations associated with GUI operations, testing should be approached using automated tools. A wide array of GUI testing tools has appeared on the market over the past few years.

Software Engineering MC0071

Roll No. 521150974

Testing Documentation and Help Facilities The term software testing conjures images of large numbers of test cases prepared to exercise computer programs and the data that they manipulate. From the definition of software, it is important to note that testing must also extend to the third element of the software configurationdocumentation. Errors in documentation can be as devastating to the acceptance of the program as errors in data or source code. Nothing is more frustrating than following a user guide or an on-line help facility exactly and getting results or behaviors that do not coincide with those predicted by the documentation. it is for this reason that that documentation testing should be a meaningful part of every software test plan. Documentation testing can be approached in two phases. The first phase, review and inspection, examines the document for editorial clarity. The second phase, live test, uses the documentation in conjunction with the use of the actual program. Surprisingly, a live test for documentation can be approached using techniques that are analogous to many of the black-box testing methods discussed in Section 17.6. Graph-based testing can be used to describe the use of the program; equivalence partitioning and boundary value analysis can be used to define various classes of input and associated interactions. Program usage is then tracked through the documentation. The following questions should be answered during both phases: Does the documentation accurately describe how to accomplish each mode of use? Is the description of each interaction sequence accurate? Are examples accurate? Are terminology, menu descriptions, and system responses consistent with the actual program? Is it relatively easy to locate guidance within the documentation? Can troubleshooting be accomplished easily with the documentation? Are the document table of contents and index accurate and complete?

Software Engineering MC0071

Roll No. 521150974

 Is the design of the document (layout, typefaces, indentation, graphics) conducive to understanding and quick assimilation of information? Are all software error messages displayed for the user described in more detail in the document? Are actions to be taken as a consequence of an error message clearly delineated? If hypertext links are used, are they accurate and complete? If hypertext is used, is the navigation design appropriate for the information required? The only viable way to answer these questions is to have an independent third party (e.g., selected users) test the documentation in the context of program usage. All discrepancies are noted and areas of document ambiguity or weakness are defined for potential rewrite.

Software Engineering MC0071

Roll No. 521150974

Que. 3. Draw possible data flow diagram of system design for the following application. Part of the electronic mail system which presents a mail form to a user, accepts the completed form and sends it to the identified destination. Ans:

Software Engineering MC0071

Roll No. 521150974

Que: 4. What are the main characteristics of successful teams? Ans: The Main Characteristics of A Successful Team: A team can be defined as a group of individuals who have been organized for the purpose of working together to achieve a set of objectives that cannot be effectively achieved by the individuals working alone. The effectiveness of a team may be measured in terms ranging from its outcomes to customer acceptance, team capability, and individual satisfaction. Organizational and individual inputs significantly affect the teams inputs. The team work process is characterized by the efforts exerted towards the goal; the knowledge and skills utilized; the strategy adopted; and the dynamics of the group. Team construction and management are a critical challenge in software-driven problem solving. They require: Goal identification Strategy definition Task management Time management Allocation of resources Interdisciplinary team composition Span of control Training Team communication Team cohesiveness Quality assurance and evaluation The main characteristics of successful teams include: Shared goal. There must be a shared awareness of the common team goal among all the team members. This shared goal is the objective that directs, guides, and integrates the individual efforts to achieve the intended results. Effective collaboration. A team must work as a team. This entails collaborating, individuals making contributions, exchanging their ideas and knowledge, and building interpersonal relationships and trust. The project environment should facilitate and encourage effective collaboration and interoperation.

Software Engineering MC0071

Roll No. 521150974

 Individual capabilities. Each team member must be trained and guided so as to be able to cooperate with the other team members towards the common goal. Some other characteristics of well-functioning teams include: Sharing the mission and goal Disseminating complete information about schedules, activities and priorities Developing an understanding of the roles of each team member Communicating clear definitions of authority and decision-making lines Understanding the inevitability of conflicts and the need to resolve them Efficiently utilizing individual capabilities Effectively deploying meetings Accurately evaluating the performance of each team member Continually updating individual skills to meet evolving needs Additional indicators of effective operation include a high level of project management involvement and participation; a focus on purpose; shared responsibilities; a high degree of communication; strategically oriented thinking; and rapid response to challenges and opportunities. These team performance characteristics require every team member to contribute ideas; operate in an environment that contains a diversity of skills; appreciate the contributions of others; share knowledge; actively inquire to enhance understanding; participate energetically; and exercise flexibility.

Software Engineering MC0071

Roll No. 521150974

Que 5: Describe Classic Invalid assumptions in the context of Process Life Cycle models. Ans: Four unspoken assumptions that have played an important role in the history of software development are considered next.1. First Assumption: Internal or External Drivers : The first unspoken assumption isthat software problems are primarily driven by internal software factors. Granted thissupposition, the focus of problem solving will necessarily be narrowed to the softwarecontext, thereby reducing the role of people, money, knowledge, etc. in terms of theirpotential to influence the solution of problems.2. Second Assumption: Software or Business Processes : A second significant unspoken assumption has been that the software development process is independent of the business processes in organiza tions. This assumption implied that it waspossible to develop a successful software product independently of the businessenvironment or the busi ness goals of a firm. This led most organizations and businessfirms to separate software development work, people, architecture, and planning frombusiness processes. This separation not only isolated the software-related activities, but also led to different goals, backgrounds, configurations, etc. for software as opposed tobusiness processes.3. Third Assumption: Processes or Projects : A third unspoken assumption was that the software project was separate from the software process. Thus, a software processwas understood as reflecting an area of computer science concern, but a softwareproject was understood as a business school interest. If one were a computer sciencespecialist, one would view a quality software product as the outcome of a development process that involved the use of good algo rithms, data base design, and code. If onewere an MIS specialist, one would view a successful software system as the result of effective software economics and software management.4. Fourth Assumption: Process Centred or Architecture Centred : There arecurrently two broad approaches in software engineering; one is process centred and theother is architecture centred. In process-centred software engineering, the quality of theproduct is seen as emerging from the quality of the process. This approach reflects theconcerns and interests of industrial engineering, management, and standardized orsystematic quality assurance approaches such as the Capability Maturity Model and ISO.The viewpoint is that obtaining quality in a product requires adopting andimplementing a correct problem-solving approach. If a product con tains an error, oneshould be able to attribute and trace it to an error that occurred somewhere during theapplication of the process by carefully examining each phase or step in the process.
Software Engineering MC0071 Roll No. 521150974

Que 6: Describe the following: a. Importance of people in problem solving process. b. Human driven software engineering.

Ans: 6(a). Importance of people in problem solving process It is useful to have a structure to follow to make sure that nothing is overlooked. Nothing here is likely to be brand new to anyone, but it is the pure acknowledgement and reminding of the process that can help the problems to be solved. 1. Problem Definition The normal process for solving a problem will initially involve defining the problem you want to solve. You need to decide what you want achieve and write it down. Often people keep the problem in their head as a vague idea and can so often get lost in what they are trying to solve that no solution seems to fit. Merely writing down the problem forces you to think about what you are actually trying to solve and how much you want to achieve. The first part of the process not only involves writing down the problem to solve, but also checking that you are answering the right problem. It is a check-step to ensure that you do not answer a side issue or only solve the part of the problem that is most easy to solve. People often use the most immediate solution to the first problem definition that they find without spending time checking the problem is the right one to answer. 2. Problem Analysis The next step in the process is often to check where we are, what is the current situation and what is involved in making it a problem. For example, what are the benefits of the current product/service/process? And why did we decide to make it like that? Understanding where the problem is coming from, how it fits in with current developments and what the current environment is, is crucial when working out whether a solution will actually work or not. Similarly you must have a set of criteria by which to evaluate any new solutions or you will not know whether the idea is workable or not. This section of the problem solving process ensures that time is spent in stepping back and assessing the current situation and what actually needs to be changed. After this investigation, it is often good to go back one step to reconfirm that your problem definition is still valid. Frequently after the investigation people discover that the problem they really want to answer is very different from their original interpretation of it. 3. Generating possible Solutions When you have discovered the real problem that you want to solve and have investigated the climate into which the solution must fit, the next stage is to generate a number of possible solutions. At this
Software Engineering MC0071 Roll No. 521150974

stage you should concentrate on generating many solutions and should not evaluate them at all. Very often an idea, which would have been discarded immediately, when evaluated properly, can be developed into a superb solution. At this stage, you should not pre-judge any potential solutions but should treat each idea as a new idea in its own right and worthy of consideration. 4. Analyzing the Solutions This section of the problem solving process is where you investigate the various factors about each of the potential solutions. You note down the good and bad points and other things which are relevant to each solution. Even at this stage you are not evaluating the solution because if you do so then you could decide not to write down the valid good points about it because overall you think it will not work. However you might discover that by writing down its advantages that it has a totally unique advantage. Only by discovering this might you choose to put the effort in to develop the idea so that it will work. 5. Selecting the best Solution(s) This is the section where you look through the various influencing factors for each possible solution and decide which solutions to keep and which to disregard. You look at the solution as a whole and use your judgments as to whether to use the solution or not. In Innovation Toolbox, you can vote using either a Yes/No/Interesting process or on a sliding scale depending on how good the idea is. Sometimes pure facts and figures dictate which ideas will work and which will not. In other situations, it will be purely feelings and intuition that decides. Remember that intuition is really a lifetimes experience and judgments compressed into a single decision. 6. Planning the next course of action (Next Steps) This section of the process is where you write down what you are going to do next. Now that you have a potential solution or solutions you need to decide how you will make the solution happen. This will involve people doing various things at various times in the future and then confirming that they have been carried out as planned. This stage ensures that the valuable thinking that has gone into solving the problem becomes reality. This series of Next Steps is the logical step to physically solving the problem.

Ans: 6(b). Human driven software engineering. Resolvability is essential to adapting to the dynamic and changing requirements in response to the feedback from context awareness systems. However, most of current context models have limited capability in exploring human intentions that often drive system evolution. To support service requirements analysis of real-world applications in distributed service environments, this paper focuses on human-intention driven software resolvability. In our approach, requirements analysis via an evolution cycle provides the means of speculating requirement changes, predicting possible new
Software Engineering MC0071 Roll No. 521150974

generations of system behaviors, and assessing the corresponding quality impacts. Furthermore, we also discuss resolvability metrics by observing intentions from user contexts.

From the 10th RE conference site (RE'02): "Over the last ten years, RE has moved from an immature software engineering phase to a well-recognized practice and research area spanning the whole system lifecycle. RE requires a variety and richness of skills, processes, methods, techniques and tools. In addition, diversity arises from different application domains ranging from business information systems to real-time process control systems, from traditional to web-based systems as well as from the perspective being system families or not." Synonyms: Goal-driven, goal-directed, goal-oriented, goalbased. Notice that goal-directed is a trademark of Cooper Interactive Design which is why we will not use this term even though it is more popular than goal-directed, preferring the neutral term goaldriven. The Key Ideas Requirements engineering (RE) is concerned with producing a set of specifications for software systems that satisfy their stakeholders and can be implemented, deployed and maintained. Goal-driven requirements engineering takes the view that requirements should initially focus on the why and how questions rather than on the question of what needs to be implemented. "Traditional" analysis and design methods focused on the the functionality of the system to be built and its interactions with users. Instead of asking what the system needs to do, goal-driven methods ask why a certain functionality is need and how it can be implemented. Thus goal-driven methods give a rationale for system functionality by answering why a certain functionality is needed while also tracking different implementation alternatives and the criteria for the selection among these alternatives.

Software Engineering MC0071

Roll No. 521150974