Software Engineering

Software Engineering
Unit 1
Q1. Explain software process. Ans: A software development process, also known as a software development lifecycle, is a structure imposed on the development of a software product. Similar terms include software life cycleand software process. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process. Some people consider a lifecycle model a more general term and a software development process a more specific term. For example, there are many specific software development processes that 'fit' the spiral lifecycle model. Q2. Define the term software engg. Ans: Software engineering (SE) is a profession dedicated to designing, implementing, and modifying software so that it is of higher quality, more affordable, maintainable, and faster to build. It is a "systematic approach to the analysis, design, assessment, implementation, test, maintenance and reengineering of software, that is, the application of engineering to software Q3. Explain spiral model with merits and demerits. Ans: The spiral model, also known as the spiral lifecycle model, is a systems development lifecycle (SDLC) model used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is favored for large, expensive, and complicated projects.

The steps in the spiral model can be generalized as follows: 1. 2. 3. 4. The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system. A preliminary design is created for the new system. A first prototype of the new system is constructed from the preliminary design. This is usually a scaleddown system, and represents an approximation of the characteristics of the final product. A second prototype is evolved by a fourfold procedure: (1) evaluating the first prototype in terms of its strengths, weaknesses, and risks; (2) defining the requirements of the second prototype; (3) planning and designing the second prototype; (4) constructing and testing the second prototype.

5. 6. 7. 8. 9.

At the customer's option, the entire project can be aborted if the risk is deemed too great. Risk factors might involve development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer's judgment, result in a less-than-satisfactory final product. The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above. The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired. The final system is constructed, based on the refined prototype. The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime. Advantages 1. Estimates become more realistic as work progresses, because important issues are discovered earlier. 2. It is more able to cope with the changes that software development generally entails. 3. Software engineers can get their hands in and start working on a project earlier. Disadvantages 1. Highly customized limiting re-usability 2. Applied differently for each application 3. Risk of not meeting budget or schedule 4. Risk of not meeting budget or schedule Q4. Explain system engg hierarchy. Ans: Good system engineering begins with a clear understanding of context - the world view - and then progressively narrows focus until technical details are understood. System engineering encompasses a collection of top-down and bottom-up methods to navigate the hierarchy. System engineering process begins with a world of view which is refined to focus more fully on a specific domain of interest. Within a specific domain, the need for targeted system elements is analyzed. Finally, the analysis, design, and construction of targeted system element is initiated. Broad context is established at the top of the hierarchy and at the bottom, detailed technical activities are conducted. It is important for a system engineer narrows the focus of work as one moves downward in the hierarchy. System modeling is an important element of system engineering process. System engineering model accomplishes the following: - define processes. - represent behavior of the process. - define both exogenous and endogenous input to model. - represent all linkages. Some restraining factors that are considered to construct a system model are: - Assumptions that reduce number of possible permutations and variations thus enabling a model to reflect the problem in a reasonable manner. - Simplifications that enable the model to be created in a timely manner. - Limitations that help to bound the system. - Constraints that will guide the manner in which the model is created and the approach taken when the model is implemented. - Preferences that indicate the preferred architecture for all data, functions , and technology. The resultant system model may call for a completely automated or semi automated or a non automated solution. Q5. Difference between verification and validation. Ans: From a general perspective, verification and validation are often used to describe the similar process. However, from the quality assurance or testing perspective, these two are completely different terms. For developing any kind of product, for example, software, there will be some requirements. These requirements are set before the development of the product is started.

It is the job of the verification to verify that these intermediate requirements are met as the development of the product continues. The job of the validations is to verify some of the end requirements are met after the development of the product finishes. Verification is generally a continuous process. The development of a product are divided i nto several cycles, each cycle will have different requirements and objectives. There will be separate validation for each of these cycles. The validati on process will validate the requirements and trace back to the original objectives. Validation, on the other hand, is not continues. After the end product is finished, the process of validation begins. It will have some original end requirements and end objectives and the verification will verify that those requirements are made and objectives are achieved. The difference can be explained further with an example. Suppose a financial software is needed to be developed. One of the requirements of the software will be to calculate daily saving. The programmer will write a function that can take the daily earnings and spending to calculate the saving. Then he will test if the function is working. This is the verification part of the job. When the software is completed, the programmer will test if it is runni ng and performs everything correctly, not only the calc ulations of daily saving but also the other functions, for example, saving the data. This is the validation process. Therefore, verification is testing a part of the product and validation is testing the whole product. Another difference between validation and verification is the timing. In the development process, the process of validation will take place before the process of verifications. Q6. Explain capability maturity model integration(CMMI). Ans: The Capability Maturity Model Integration for Software (CMMI) is a model for judging the maturity of the software processes of an organization and for identifying the key practices that are required to increase process maturity. The Software CMMI has become a de facto standard for assessing and improving software processes. Through the SW-CMMI, the SEI and community have put in place an effective means for documenting, defining, and measuring the maturity of the processes used by software professionals. Whether you are aiming for CMMI 'certification' or purely improving your software development processes Select Business Solutions has process maturity tools to help you move up through each level of maturity. Until now, no project management tools were available to truly support the evolutionary progress of IT groups, as they mature through the different CMMI levels. Select Process Director provides features that support and deliver practical CMMI benefits such as:

CMMI Level 1 to 2 Pre-packaged methodology documentation and active mentoring CMMI Level 2 to 3 Process documentation, configuration and accelerated project management CMMI Level 3 to 4 Managed process through Metrics Capture in an XML process repository CMMI Level 4 to 5 Process feedback loop to enable process improvement Q7. Explain WINWIN model with application. Ans: The spiral model suggests a framework activity that addresses customer communication. The objective of this activity is to elicit project requirements from the customer. In an ideal context, the developer simply asks the customer what is required and the customer provides sufficient detail to proceed. Unfortunately, this rarely happens. In reality, the customer and the developer enter into a process of negotiation, where the customer may be asked to balance functionality, performance, and other product or system characteristics against cost and to market. The best negotiations strive for a “win-win” result. That is, the customer wins by getting the system or product that satisfies the majority of the customer’s needs and the developer wins by working to realistic and achievable budgets and deadlines. Boehm’s WINWIN spiral model defines a set of negotiation activities at the beginning of each pass around the spiral. Rather than a single customer communication activity, the following activities are defined: 1. Identification of the system or subsystem’s key “stakeholders.” 2. Determination of the stakeholders’ “win conditions.” 3. Negotiation of the stakeholders’ win conditions to reconcile them into a set of win-win conditions for all concerned (including the software project team). Successful completion of these initial steps achieves a win-win result, which becomes the key criterion for proceeding to software and system definition. In addition to the emphasis placed on early negotiation, the WINWIN spiral model introduces three process milestones, called anchor points , that help establish the completion of one cycle around the spiral and provide decision milestones before the software project proceeds. In essence, the anchor points represent three different views of progress as the project traverses the spiral. The first anchor point, life cycle objectives (LCO), defines a set of objectives for each major software engineering activity. For example, as part of LCO, a set of objectives establishes the definition of top-level system/product requirements. The second anchor point, life cycle architecture (LCA), establishes objectives that must be met as the system and software architecture is defined. For example, as part of LCA, the software project team must demonstrate that it has evaluated the applicability of offthe-shelf and reusable software components and considered their impact on architectural decisions. Initial operational capability (IOC) is the third anchor point and represents a set of objectives associated with the preparation of the software for installation/distribution, site preparation prior to installation, and assistance required by all parties that will use or support the software. Q8. Explain the development process of software. Ans: A software development process or life cycle is a structure imposed on the development of a software product. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process. Processes More and more software development organizations implement process methodologies. The Capability Maturity Model (CMM) is one of the leading models. Independent assessments can be used to grade organizations on how well they create software according to how they define and execute their processes. Process Activities/Steps Software Engineering processes are composed of many activities, notably the following:

Requirements Analysis o Extracting the requirements of a desired software product is the first task in creating it. While customers probably believe they know what the software is to do, it may require skill and experience in software engineering to recognize incomplete, ambiguous or contradictory requirements. Specification o Specification is the task of precisely describing the software to be written, in a mathematically rigorous way. In practice, most successful specifications are written to understand and fine-tune applications that were already well-developed, although safety-critical software systems are often carefully specified prior to application development. Specifications are most important for external interfaces that must remain stable. Software architecture o The architecture of a software system refers to an abstract representation of that system. Architecture is concerned with making sure the software system will meet the requirements of the product, as well as ensuring that future requirements can be addressed. Implementation o Reducing a design to code may be the most obvious part of the software engineering job, but it is not necessarily the largest portion. Testing o Testing of parts of software, especially where code by two different engineers must work together, falls to the software engineer. Documentation o An important task is documenting the internal design of software for the purpose of future maintenance and enhancement. Training and Support o A large percentage of software projects fail because the developers fail to realize that it doesn't matter how much time and planning a development team puts into creating software if nobody in an organization ends up using it. People are occasionally resistant to change and avoid venturing into an unfamiliar area, so as a part of the deployment phase, its very important to have training classes for the most enthusiastic software users (build excitement and confidence), shifting the training towards the neutral users intermixed with the avid supporters, and finally incorporate the rest of the organization into adopting the new software. Users will have lots of questions and software problems which leads to the next phase of software. Maintenance Maintaining and enhancing software to cope with newly discovered problems or new requirements can take far more time than the initial development of the software. Not only may it be necessary to add code that does not fit the original design but just determining how software works at some point after it is completed may require significant effort by a software engineer. About 60% of all software engineering work is maintenance, but this statistic can be misleading. A small part of that is fixing bugs. Most maintenance is extending systems to do new things, which in many ways can be considered new work. Q9. What are the concept of 4P in software engg. Ans: In the SE-class platform, the 4-Ps map to a SE course as follows: • People – the instructor and all students in the class • Project – a single project for all people in one semester • Product – one complete release of a software product • Process – the Unified Software Development Process PEOPLE “People: The architects, developers, testers, and their supporting management, plus users, customers, and other stakeholders are the prime movers in a software project. In the SE-class platform, the instructorand the students play all the above roles. 1. Multi-role To understand the different roles of ‘people’, each student plays different parts and works cooperatively with others. In each stage of the project, the roles played should be explicitly indicated. Each student will

understand the title and the responsibility of the role and know whom to contact in order to solve a specific problem in each workflow (or phase) of the software development process. 2. Team Members No matter which specific roles each student takes, the most important one he/she must learn is the role of team member. The purpose of assigning students the roles mentioned in 1 is to help them to understand who should do what when in a complete software development process, while training students to be good team members helps foster the right working attitude to prepare them for work in the real world after graduation. 3. Communication Communication is a team member’s most basic and important skill. It is also one that most students are weak in. The typical problems that may seriously affect the progress of the project are: • Students do not check or reply to the e-mails related to the project. • Students are not used to discussing the project out of the class. They discuss them in class or the group meeting time only. • Students have little chance to meet after class • Students do not ask for help when they have problems that potentially jeopardize the project. PROJECT In the SE-class platform, students have a chance to get seriously involved in project management at different levels besides learning the concepts from lecture. 1. What Students Can Do The following are some aspects of project management that students may participate in within different stages of the project: 1) Meetings - There are three levels of meetings in the SE class platform: 1) department, 2) team and 3) team leaders with the supervisor. Students can learn meeting management through the different styles of meetings and understand the importance of meetings for a successful project. 2) Estimation - Offer more than one possible product to the students at the beginning of the semester. Under the guidance of the instructor, the students estimate the time limitation, the possible artifacts that will have to be packed in the product, and the resources needed including people, existing systems, tools and lab environment. Based on the estimates, the students pick the product they want to do. Through participating in the product estimates, the students tend to be more responsible for the project they decide to do. 3) Task scheduling - Since students have no idea which exact activities they will do at the beginning of the project, the instructor should make a rough schedule for the whole project. Under the project schedule, the students can participate in the planning of the subschedule for each workflow or mini project. 4) Risk management – Some things that cause project failure in the real world, like cost overruns, never occur in a SE class project. However, the following risks are possible: wrong self-cognition in survey, misunderstanding between team members or teams, the work of one person or one team is behind schedule, and a key person dropping from the class during the semester. 2. Workload Distribution Models There are two ways to assign the tasks of the project to students: Vertical style – One student plays a limited role in the project by focusing on the tasks in some specific area. Horizontal style – Every student plays as many key roles as possible in every workflow. This will allow students to gain wider ranges of knowledge and skills 3. Project Control 1 Project Size Control So far, all projects selected for experimental classes based on the SE-class platform have been in the business software category: a Student Information Management system, a Hotel Reservation system, and an Online Book Store. The size of a chosen project depends on the size of the class and the “human resources”. The functions of each product can be prioritized and divided into components. After identifying the key functions that must be implemented, the rest of system functions can be organized into optional service packs to balance the workload among teams. For example, in the Online Book Store system, the required functions are browsing, searching and purchasing, and the optional extended functions include login, stocking, billing, shipping, etc. A class with a larger size works from a larger core function (use case) set, while a smaller class from a smaller set. Normally, the number of use cases identified in requirement elicitation tends to be larger than the number finally implemented.

2 Risk Control Some possible risks in large SE class projects have been listed. One of the most difficult problems is when one person or one team is behind schedule. When one person is behind, the problem generally is that the student is weak or does not take responsibility. The following strategies are used in the platform to solve the problem: 1) The report scheme allows the supervisor to watch each student’s progress closely and to identify the problems as early as possible. 2) For a slow task, we first try to help the student with a team meeting or lab in which the student can get detailed advice on his/her work. This normally works for the serious students. 3) Otherwise, the task is assigned to some strong student(s) in the team as a backup and extra credit is given to the helper(s). Since the tasks are distributed in each workflow, the workload for one person in one development activity is not very heavy, and a strong student normally can handle extra workloads PRODUCT The correctness of the artifacts created in each development activity is a key criterion in evaluating the results of our teaching. In the SE-class platform, 1. Domain Knowledge In order for students to learn requirements collection and elicitation, each project starts from a vague text description of the product. To obtain the correct requirements, the students have to learn the basic business domain knowledge. 2. Entity Classes In general, it is not difficult for students to identify entity classes, especially after the domain model has been created. The hard parts are that identify relationships between entity classes, and implement persistent data storage without using a database in a complicate system. 3. API or IPI? During the design workflow, the students create the APIs of assigned classes and submit them at the end of the workflow. However, many students do not follow the design decisions but change the interface by themselves. I call this “I preferred interface (IPI)” PROCESS The Unified Process not only consists of the core software development workflows like other typical processes, but uniquely features three software engineering methodologies: use-case driven, architecture centric, and iterative and incremental. This section discusses how students learn those methodologies through the project. 1. Use-case Driven The use case realization is an activity occurred in workflows to transform the requirements into the product. As a use cases’ owner, each student has to be responsible to guarantee that the use cases he/she owns will eventually be implemented and function properly in the system. This may include: • Writing detailed descriptions of the use cases • Identifying analysis classes and design classes from the use cases • Creating the collaboration diagrams and sequence diagrams of the use cases in analysis and design • Cooperatively working with teammates and other teams to decide a unique list of all classes • Implementing assigned classes • Testing the use cases 2. Architecture centric System architecture is usually very vague to the students when first introduced in lecture. In the Unified Process, the architecture is described by the views of the models in each workflow. The activities related to the architecture permeate almost all the workflows 3. Iterative and Incremental Due to the limitations of the project size, the available time, and human resources (the students cannot be treated as real experienced developers), one project cannot include many iterations. Another issue is that the initial iteration may not include all the core use cases.

Unit 2
Q1. Define behavioral model. Ans: Behavioral model used to describe overall behavior of the system. There are two types of behavioral models: 1. Data processing model 2. State machine model Q2. What is data dictionary. Ans: A data dictionary is a collection of descriptions of the data objects or items in a data model for the benefit of programmers and others who need to refer to them. A first step in analyzing a system of objects with which users interact is to identify each object and its relationship to other objects Q3. Define legacy system. Ans: A legacy system is an old method, technology, computer system, or application program that continues to be used, typically because it still functions for the users' needs, even though newer technology or more efficient methods of performing a task are now available. A legacy system may include procedures or terminology which are no longer relevant in the current context, and may hinder or confuse understanding of the methods or technologies used. Q4. What is the use of s/w document. Ans;Software documentation or source code documentation is written text that accompanies computer software. It either explains how it operates or how to use it, and may mean different things to people in different roles. Q5. Explain requirement engg. Process. Ans: A requirements engineering process is a structured set of activities that is done to develop, validate and maintain a system requirements document. Activities involved in requirements engineering process are requirements elicitation, requirements analysis and negotiation, requirements documentation and requirements validation. Requirements elicitation. The system requirements are known by consulting the end users, project managers, from domain knowledge, from existing system documentation and other relevant sources. Other names for requirements elicitation are requirements acquisition or requirements discovery. Requirements Analysis . There requirements are analyzed for necessity of the requirements, consistency and completeness checking and whether the requirements are feasible in terms of budget and time. Requirements Negotiation Problematic requirements are identified and discussed to solve it. Stakeholders and software developers finally agree to make the necessary changes and finalize with set of agreed requirements. Requirements Documentation. The agreed requirements are documented using natural language which is understandable by all stakeholders. Supporting diagrams such use case diagrams or sequence diagrams are incorporated in the document to give higher level of details. Requirements Validation The agreed requirements are checked for consistency and completeness to detect any problem is the requirements before it used to develop the system. This activity will help to minimize cost of the fixing errors in the early stage of system development.

Q6. Explain software prototyping with advantage and disadvantages. Ans: Prototyping is the process of building a model of a system. In terms of an information system, prototypes are employed to help system designers build an information system that intuitive and easy to manipulate for end users. Prototyping is an iterative process that is part of the analysis phase of the systems development life cycle. During the requirements determination portion of the systems analysis phase, system analysts gather information about the organization's current procedures and business processes related the proposed information system. In addition, they study the current information system, if there is one, and conduct user interviews and collect documentation. This helps the analysts develop an initial set of system requirements. Prototyping can augment this process because it converts these basic, yet sometimes intangible, specifications into a tangible but limited working model of the desired information system. The user feedback gained from developing a physical system that the users can touch and see facilitates an evaluative response that the analyst can employ to modify existing requirements as well as developing new ones. Prototyping comes in many forms - from low tech sketches or paper screens(Pictive) from which users and developers can paste controls and objects, to high tech operational systems using CASE (computeraided software engineering) or fourth generation languages and everywhere in between. Many organizations use multiple prototyping tools. For example, some will use paper in the initial analysis to facilitate concrete user feedback and then later develop an operational prototype using fourth generation languages, such as Visual Basic, during the design stage. Advantages of Prototyping: Reduces development time. Reduces development costs. Requires user involvement. Developers receive quantifiable user feedback. Facilitates system implementation since users know what to expect. Results in higher user satisfaction. Exposes developers to potential future system enhancements. Disadvantages of Prototyping Can lead to insufficient analysis. Users expect the performance of the ultimate system to be the same as the prototype. Developers can become too attached to their prototypes Can cause systems to be left unfinished and/or implemented before they are ready. Sometimes leads to incomplete documentation. If sophisticated software prototypes (4th GL or CASE Tools) are employed, the time saving benefit of prototyping can be lost. Q7. Explain structure of requirement document. Ans; Table of Contents from a sample requirements document:

1. 1. 2.

Introduction - an overview into what this document is about and also the objective and scope. Business Overview - the business objective should state why this project is being undertaken from a business point of view. Project Scope - are-iteration of the project scope and what is to be done with this project and what is to be left for future projects. This should contain as much detail as possible and should include a matrix of key pages to be worked on during design. User Analysis - provides a high level overview of who the users of the digital property are and what they might be doing on once they arrive. Audience - looks at who the various audiences are and why they would be coming to the site. Included should be the various high level take aways that the audiences will walk away from the project with. Personas - defines some sample users of the site. Typically will include some demographic / psychographic information about the personal, Use cases - define how the various personas would interact with the site. This will show how the users would actually navigate within the site, what functions they would expect to find, and what the expected result would be. User Experience Requirements - shows how the users will experience and interact with the site. Site map - shows the organization or “bucketing” of information into primary, secondary, and tertiary navigation items. Use flows - the use flows show certain decision paths as outlined by the use cases. The user flows are meant to show how a user (admin or end user) will interact with the site. Key page wireframes - for those pages considered “key” to the design, wireframes will be produced. The wireframes are used to build final consensus as to what functions and information each page will contain. Future enhancements - Future enhancements are items that should be documented and taken into account when designing the site, architecture, technology, etc. Marketing requirements - The marketing requirements will define how the users will be brought to the site and messaged. The marketing requirements covers the types of campaigns to be conducted and what the desired spends are for each In Scope requirements Requested enhancements Future enhancements End User functional requirements - The end user functional requirements describe what the site visitor is able to do when they interact with the site. This will be a full inventory of the activities and functions for all the various types of users. In Scope requirements Requested enhancements Future enhancements Administrative functional requirements - Like the end user, all administrative functions need to be described. Administrative functions are functions performed by members of the host organization (client) or their affiliates who log in with a password to perform certain actions to maintain the website. In Scope requirements Requested enhancements Future enhancements

2. 1.

2. 3.

4. 1. 2. 3.

5. 6.

1. 2. 3. 7.

1. 2. 3. 8.

1. 2. 3.

9.

Technical requirements - should spell out what the requirements are for the system, the core software, front end, and tracking and measurement.

10. System and hosting requirements - will spell out how much traffic (number of users, amount of data in the system, concurrent page views, reads vs. writes, etc) the site will be able to handle. The requirements will state where the site needs to be hosted and on what base architecture (OS, DB, Web Server). 11. Updated project plan - the updated project plan should be provided as the final part of the requirements document. Any changes from the original plan should be noted and more details should be provided 12. Appendix A - Assumptions - this will capture all the technical, creative, brand, user, admin, and content assumptions made while creating the proposal and requirements document. 13. Appendix B - Scope Changes - In a tabular format, this section captures all of the current and future scope changes. It summarizes each, approximate level of effort (sometimes in people days, sometimes as low, medium and high). Q8. Explain functional and non-functional requirement in detail Ans; Functional Requirement (Function) A Functional Requirement is a requirement that, when satisfied, will allow the user to perform some kind of function. For example: “The customer must place an order within two minutes of registering” For the most part, when people are talking about Business Requirements, they are referring to Functional Requirements which are generally referred to as “requirements”. Functional Requirements have the following characteristics: uses simple language not ambiguous contains only one point specific to one type of user is qualified describes what and not how Typical functional requirements are: Business Rules Transaction corrections, adjustments, cancellations Administrative functions Authentication Authorization –functions user is delegated to perform Audit Tracking External Interfaces Certification Requirements Reporting Requirements Historical Data Legal or Regulatory Requirements Non-Functional Requirement A Non-Functional Requirement is usually some form of constraint or restriction that must be considered when designing the solution. For example: “The customer must be able to access their account 24 hours a day, seven days a week.” For the most part when people are talking about Constraints, they are referring to Non-Functional Requirements. Non-Functional Requirements have the same following characteristics: uses simple language not ambiguous

contains only one point specific to one type of user is qualified describes what and not how Non-Functional requirements tend to identify “user” constraints and “system” constraints. Business requirements should be kept pure and not reflect any solution thinking. Typical non-functional requirements are: Performance - Response Time, Throughput, Utilization, Static Volumetric Scalability Capacity Availability Reliability Recoverability Maintainability Serviceability Security Regulatory Manageability Environmental Data Integrity Usability Interoperability Q9. Explain 1) Behavioral model Behavioral Modeling contains a set of tools for performing a wide variety of analyses on a model and incorporating the analysis results into the model. Behavioral Modeling lets you modify the model design to reflect the desired solution . You use the Behavioral Modeling tools to: •Create feature parameters based on measurements and analyses of the model. •Create geometric entities based on measurements and analyses of the model. •Create new types of measurements tailored to application-specific needs. •Analyze the behavior of measured parameters as variable dimensions and parameters change. •Automatically find dimension and parameter values that achieve a desired behavior of the model. •Analyze the behavior of measured parameters within a specified design space. The basic building blocks of Behavioral Modeling are: •Field point •Analysis feature •Persistent analysis display •User-Defined Analysis (UDA) •Sensitivity, Feasibility, and Optimization Studies •Optimization feature •Multi-Objective Design studies •External Analysis •Motion Analysis 2) Data model Data modeling is the formalization and documentation of existing processes and events that occur during application software design and development. Data modeling techniques and tools capture and translate complex system designs into easily understood representations of the data flows and processes, creating a blueprint for construction and/or re-engineering. A data model can be thought of as a diagram or flowchart that illustrates the relationships between data. Although capturing all the possible relationships in a data model can be

very time-intensive, it's an important step and shouldn't be rushed. Well-documented models allow stake-holders to identify errors and make changes before any programmingcode has been written. Data modelers often use multiple models to view the same data and ensure that all processes, entities, relationships and data flows have been identified. There are several different approaches to data modeling, including: Conceptual Data Modeling - identifies the highest-level relationships between different entities. Enterprise Data Modeling - similar to conceptual data modeling, but addresses the unique requirements of a specific business. Logical Data Modeling - illustrates the specific entities, attributes and relationships involved in a business function. Serves as the basis for the creation of the physical data model. Physical Data Modeling - represents an application and database-specific implementation of a logical data model. 3) Functional model In contrast, the functional model that this paper advocates is strictly based upon the correspondence of software configuration tasks to the tasks found in the basic software development model. The basic software development model, according to Sommerville (1996), who is the author of one of the most commonly used textbooks on software engineering and consequently one that most people might be familiar with, consists of four fundamental activities which are common to all software development processes: software specification, software development, software validation, and software evolution. The functional model of configuration management maps the functions of version control, documentation control, change management, build management, and release control to the development model. The model is called a "functional" model because the typology is based on tasks that are commonly called out on a WBS (Work Breakdown Structure) and there is no need for interpretation of task versus configuration management area type. A functional emphasis is important for the E-World, i.e. web applications, because all actions must be as time-efficient as possible to meet deadlines and yet control of baselines and changes must still occur. There is not the luxury of pondering over what configuration management means according to some abstract model, but rather a driving concern with getting tangible tasks performed quickly. A "functional" model is focused on getting those tasks done, not with generating paper. Mapping the functional software configuration model to the development model, version control takes place at the conclusion of development with formal software baselines prior to validation. Documentation control takes place at the conclusion of specification and then continues throughout with traceability of documents to software baselines. Change management is initiated immediately following the first instance of the use of version control or document control. Build management occurs with the initial repeatable documentation of how to construct the first formal baseline with updates then being a constant necessity. And release control is performed at the conclusion of validation such that all versions of the system that are released to outside parties are approved, recorded, and tracked against requests for defect resolution and enhancements. A description of typical tasks and activities for each functional area follows and is organized on the basis of "What", "Why, "When", "Where", "Who", and "How" for the purposes of clarity and definition. In addition, the special needs and consideration of web applications will be discussed. Q10. Explain different approaches used in user interface prototyping. Ans: Prototyping is a development approach used to improve planning and execution of software projects by executable software systems (prototypes) for experimental purposes. It is very suitable for gaining experience in new application areas and for supportingincremental or evolutionary software development.

Approaches to user interface prototyping For classifying approaches to prototyping, Floyd's three "E" model is widely accepted and used in Europe. Differences exist in the interpretation of the "E"s: exploratory, experimental and evolutionary. We distinguish two different approaches: the process view which concentrates on the development process and its goals and the product view which concentrates on the results of the process .In the following we discuss only the process view. An extensive discussion of the terminology can be found in . • Exploratory Prototyping serves to clarify the requirements and potential solutions. It results in discussions of what should be achieved by a task and how it can be supported with IT. Results are usually presentation prototypes and functional prototypes. • Experimental Prototyping focuses on the technical realization of selected requirements. It results in experience about the suitability and feasibility of a particular design/implementation. Results are usually functional prototypes and breadboards. • Evolutionary Prototyping is a continuous process for adapting an application system to rapidly changing organizational constraints. It is not merely used in the context of a single project. Although in the process of evolutionary prototyping all kinds of prototypes may be built, the construction of pilot systems is of particular importance. 2.2 Classification of user interface prototypes Besides classifying the different approaches to prototyping it is also important to classify the different kinds of prototypes that can be built. • Presentation Prototypes are built to illustrate how an application may solve given requirements. As they are often used as part of the project proposal, they are strongly focused on the user interface. • Functional Prototypes implement strategically important parts of both the user interface and the functionality of a planned application. • Breadboards serve to investigate technical aspects such as system architecture or functionality of a planned application. They are built to investigate certain aspects of special risk. They are not intended to be evaluated by end users. • Pilot systems are very mature prototypes which can be practically applied

Unit 3
Q1. What is SCM ? what its need? Ans: In software engineering, software configuration management (SCM) is the task of tracking and controlling changes in the software. Configuration management practices include revision control and the establishment of baselines. Q2. Define abstraction in design process of software. Ans: Abstraction Abstraction is a tool that permits a designer to consider a component at an abstract level without worrying about the details of the implementation of the component. An abstraction of a component describes the external behavior of that component without bothering with the internal details that produce the behavior. Abstraction is an indispensable part of the design process and is essential for problem partitioning Q3. What do you mean by modular design. Ans: In systems engineering, modular design — or "modularity in design" — is an approach that subdivides a system into smaller parts (modules) that can be independently created and then used in different systems to drive multiple functionalities. A modular system can be characterized by the following: (1) Functional partitioning into discrete scalable, reusable modules consisting of isolated, self-contained functional elements; (2) Rigorous use of well-defined modular interfaces, including object-oriented descriptions of module functionality; (3) Ease of change to achieve technology transparency and, to the extent possible, make use of industry standards for key interfaces. Q4. Explain SCM in detail. Ans: The traditional software configuration management (SCM) process is looked upon by practitioners as the best solution to handling changes in software projects. It identifies the functional and physical attributes of software at various points in time, and performs systematic control of changes to the identified attributes for the purpose of maintaining software integrity and traceability throughout the software development life cycle. The SCM process further defines the need to trace changes, and the ability to verify that the final delivered software has all of the planned enhancements that are supposed to be included in the release. It identifies four procedures that must be defined for each software project to ensure that a sound SCM process is implemented. They are: 1. 2. 3. 4.  Configuration identification Configuration control Configuration status accounting Configuration audits

These terms and definitions change from standard to standard, but are essentially the same. Configuration identification is the process of identifying the attributes that define every aspect of a configuration item. A configuration item is a product (hardware and/or software) that has an enduser purpose. These attributes are recorded in configuration documentation and baselined. Baselining an attribute forces formal configuration change control processes to be effected in the event that these attributes are changed. Configuration change control is a set of processes and approval stages required to change a configuration item's attributes and to re-baseline them. Configuration status accounting is the ability to record and report on the configuration baselines associated with each configuration item at any moment of time. Configuration audits are broken into functional and physical configuration audits. They occur either at delivery or at the moment of effecting the change. A functional configuration audit ensures that functional and performance attributes of a configuration item are achieved, while a physical

  

configuration audit ensures that a configuration item is installed in accordance with the requirements of its detailed design documentation. Configuration management is widely used by many military organizations to manage the technical aspects of any complex systems, such as weapon systems, vehicles, and information systems. The discipline combines the capability aspects that these systems provide an organization with the issues of management of change to these systems over time. Q5. Explain various types of cohesion and coupling. Ans: Coupling is a measure of independence of a module or component. Loose coupling means that different system components have loose or less reliance upon each other. Hence, changes in one component would have a limited affect on other components. Strong cohesion implies that all parts of a component should have a close logical relationship with each other. That means, in the case some kind of change is required in the software, all the related pieces are found at one place. Hence, once again, the scope is limited to that component itself. A component should implement a single concept or a single logical entity. All the parts of a component should be related to each other and should be necessary for implementing that component. If a component includes parts that are not related to its functionality, then the component is said to have low cohesion. Coupling and cohesion are contrasting concepts but are indirectly related to each other. Cohesion is an internal property of a module whereas coupling is its relationship with other modules. Cohesion describes the intra-component linkages while couple shows the inter-component linkages. Coupling measures the interdependence of two modules while cohesion measures the independence of a module. If modules are more independent, they will be less dependent upon others. Therefore, a highly cohesive system also implies less coupling. Example of Coupling The modules that interact with each other through message passing have low coupling while those who interact with each other through variables that maintain information about the state have high coupling. The following diagram shows examples of two such systems.

Example of Cohesion As mentioned earlier, strong cohesion implies that all parts of a component should have a close logical relationship with each other. That means, in case some kind of change is required in the software, all the related pieces are found at one place. A class will be cohesive if most of the methods defined in a class use most of the data members most of the time. If we find different subsets of data within the same class being manipulated by separate groups of functions then the class is not cohesive and should be broken down as shown below. Class X1

Q6. Explain various kinds of design. Ans: Design patterns are mainly of three types Creational Structural Behavioral Creational Pattern In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation. Creational design patterns are further categorized into Object-creational patterns and Class-creational patterns. Where, Objectcreational patterns deal with Object creation and Class-creational deal with Class-instantiation. Structural Pattern In software engineering, structural design patterns are design patterns that ease the design by identifying a simple way to realize relationships between entities. Behavioral Pattern In software engineering, behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this communication. Q7. Define software design process. What are the good characteristics of good design? Ans; A software development process, also known as a software development lifecycle, is a structure imposed on the development of a software product. Similar terms include software life cycle and software process. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process. Some people consider a lifecycle model a more general term and development process a more specific term. The design process for the software has two levels. 1. system design or top-level design 2. detailed design or logic design software Design would have all these characteristics, but that’s almost never possible. Some of them contradict each other, so often we have to make tradeoffs. Anyway, here’s the list: Minimal complexity – if your design doesn’t let you safely ignore most other parts of the program when you’re immersed in one specific part, the design isn’t doing its job. This is also known as avoiding complexity. Ease if maintenance - design the system to be self-explanatory. Wheter it’s yourself or a maintainance programmer that’s going to sit down and fix a bug in a couple of months time it’ll be worth it.

Loose coupling – Loose coupling means designing so that you hold connections among different parts of a program to a minimum. This means; encapsulation, and information hiding [read] and good abstractions in class interfaces. This also makes the stuff easier to test, which is a Good Thing. Extensibility – You can change a piece of the system without affecting other pieces. Reusability – Designing the system so that you can use pieces of it in other systems. High fan-in – This refers to having a high number of classes that use a given class. This is good, the opposite on the other hand … Low-to-medium fan-out – Refers to how many classes a given class use. If a class have a high fanout (Code Complete says this is more than 7 classes, I don’t want to be that specific) this is often an indication of that the class may be overly complex. And complexity is bad, remember? Portability – How easy would it be to move the system to another environment? Leanness - I guess this could be compared to KISS. Voiltaire said that a book is finished not when nothing more can be added but when nothing more can be taken away. Extra code will have to be developed, reviewed, tested, and considered when the other code is modified. Stratification – designing “in layers”. Can you view “one layer” of the code without thinking about the underlying layer? An example giving in Code Complete is if you’re writing a modern system that has to use a lot of older, poorly designed code – you would want to write a layer of the new system that is responsible for interfacing with the old code. Standard techniques – this means using design patterns whenever it is appropiate to do so. This way, if you say to another coder “Here I use the Factory pattern” he will instantly know what you’re talking about if he knows the pattern. You do not want to be one of those “valued employees” who only write code that the “valued employee” can understand. Q8. Explain architectural design process. Ans: The design process for identifying the subsystems making up a system and the framework for subsystem control and communication is architectural design. ● The output of this design process is a description of the software architecture. Architectural design ● An early stage of the system design process. ● Represents the link between specificationand design processes. ● Often carried out in parallel with some specification activities. ● It involves identifying major system components and their communications. Advantages of explicit architecture ● Stakeholder communication Architecture may be used as a focus of discussion by system stakeholders. ● System analysis Means that analysis of whether the system can meet its non-functional requirements is possible. ● Large-scale reuse The architecture may be reusable across a range of system. Architecture and system characteristics ● Performance Localise critical operations and minimise communications. Use large rather than fine-grain components. ● Security Use a layered architecture with critical assets in the inner layers. ● Safety Localise safety-critical features in a small number of subsystems. ● Availability Include redundant components and mechanisms for fault tolerance. ● Maintainability Use fine-grain, replaceable components. Q9. Explain interface design. Ans: User interface design or user interface engineering is the design of computers, appliances, machines, mobile communication devices,software applications, and websites with the focus on the user's

experience and interaction. The goal of user interface design is to make the user's interaction as simple and efficient as possible, in terms of accomplishing user goals—what is often called user-centered design. Good user interface design facilitates finishing the task at hand without drawing unnecessary attention to itself. Graphic design may be utilized to support its usability. The design process must balance technical functionality and visual elements (e.g., mental model) to create a system that is not only operational but also usable and adaptable to changing user needs. UI Design Principles Let’s start with the fundamentals of user interface design. Constantine and Lockwood describe a collection of principles for improving the quality of your user interface design. These principles are 1. The structure principle. Your design should organize the user interface purposefully, in meaningful and useful ways based on clear, consistent models that are apparent and recognizable to users, putting related things together and separating unrelated things, differentiating dissimilar things and making similar things resemble one another. The structure principle is concerned with your overall user interface architecture. The simplicity principle. Your design should make simple, common tasks simple to do, communicating clearly and simply in the user’s own language, and providing good shortcuts that are meaningfully related to longer procedures. The visibility principle. Your design should keep all needed options and materials for a given task visible without distracting the user with extraneous or redundant information. Good designs don’t overwhelm users with too many alternatives or confuse them with unneeded information. The feedback principle. Your design should keep users informed of actions or interpretations, changes of state or condition, and errors or exceptions that are relevant and of interest to the user through clear, concise, and unambiguous language familiar to users. The tolerance principle. Your design should be flexible and tolerant, reducing the cost of mistakes and misuse by allowing undoing and redoing, while also preventing errors wherever possible by tolerating varied inputs and sequences and by interpreting all reasonable actions reasonable. The reuse principle. Your design should reuse internal and external components and behaviors, maintaining consistency with purpose rather than merely arbitrary consistency, thus reducing the need for users to rethink and remember.

2. 3. 4. 5.

6.

Q10. Explain transform and transaction mapping. Ans: TRANSFORM MAPPING It is a set of design steps that allows a data flow diagram with transform flow characteristics to be mapped into a specific architectural style. - Review the fundamental system model. - Review and refine data flow diagrams for the software. - Determine whether the data flow diagram has transform or transaction flow characteristics. - Isolate the transform center by specifying incoming and outgoing flow boundaries. - Perform first level factoring. - Perform second level factoring. - Refine the first iteration architecture using design heuristics for improved software quality. TRANSACTION MAPPING In transaction mapping, information flow along two of the three action paths accommodates additional incoming flow. Each action path flows into a single transform, display messages and status. The design steps for transaction mapping is similar with a major difference lies in mapping of data flow diagram to software structure. - Review the fundamental system model. - Review and refine data flow diagrams for the software. - Determine whether the data flow diagram has transform or transaction flow characteristics.

- Identify the transaction center and the flow characteristics along each of the action paths. - Map the data flow diagram in a program structure amenable to transaction processing. - Factor and refine the transaction structure and the structure of each action path. - Refine the first iteration architecture using design heuristics for improved software quality. Q11. Explain DFD. Ans:ow Diagrams - Introduction Data flow diagrams can be used to provide a clear representation of any business function. The technique starts with an overall picture of the business and continues by analyzing each of the functional areas of interest. This analysis can be carried out to precisely the level of detail required. The technique exploits a method called top-down expansion to conduct the analysis in a targeted way.

The result is a series of diagrams that represent the business activities in a way that is clear and easy to communicate. A business model comprises one or more data flow diagrams (also known as business process diagrams). Initially a context diagram is drawn, which is a simple representation of the entire system under investigation. This is followed by a level 1 diagram; which provides an overview of the major functional areas of the business. Don't worry about the symbols at this stage, these are explained shortly. Using the context diagram together with additional information from the area of interest, the level 1 diagram can then be drawn. Data Flow Diagrams – Diagram Notation There are only five symbols that are used in the drawing of business process diagrams (data flow diagrams). These are now explained, together with the rules that apply to them.

This diagram represents a banking process, which maintains customer accounts. In this example, customers can withdraw or deposit cash, request information about their account or update their account details. The five different symbols used in this example represent the full set of symbols required to draw any business process diagram. External Entity

An external entity is a source or destination of a data flow which is outside the area of study. Only those entities which originate or receive data are represented on a business process diagram. The symbol used is an oval containing a meaningful and unique identifier. Process

A process shows a transformation or manipulation of data flows within the system. The symbol used is a rectangular box which contains 3 descriptive elements: Firstly an identification number appears in the upper left hand corner. This is allocated arbitrarily at the top level and serves as a unique reference. Data Flow

A data flow shows the flow of information from its source to its destination. A data flow is represented by a line, with arrowheads showing the direction of flow. Information always flows to or from a process and may be written, verbal or electronic. Data Store

A data store is a holding place for information within the system: It is represented by an open ended narrow rectangle. Data stores may be long-term files such as sales ledgers, or may be short-term accumulations Resource Flow

A resource flow shows the flow of any physical material from its source to its destination. For this reason they are sometimes referred to as physical flows. The physical material in question should be given a meaningful name. Q12. Explain version control in context with SCM. Ans: Version Control Version control is simply the automated act of tracking the changes of a particular file over time. This is typically accomplished by maintaining one copy of the file in a repository, then tracking the changes to that file (rather than maintaining multiple copies of the file itself). The concepts of check-in and check-out make this possible. Each time someone needs to edit a file, they check it out for exclusive editing and then check it back in to the repository when finished, thus creating a new version. This paradigm of check-in and check-out can be as simple as I describe above or much more complex depending on the amount of parallel development and branching you have in your process. Version control buys you a number of benefits including the ability to: Roll back to a previous version of a given file Compare two versions of a file, highlighting differences Provide a mechanism of locking, forcing serialized change to any given file Create branches that allow for parallel concurrent development Maintain an instant audit trail on each and every file: versions, modified date, modifier, and any additional amount of metadata your system provides for and you choose to implement.

Unit 4
Q1. What is difference between white box testing and Black box testing ? Ans: White box testing or unit testing : To do white box testing knowledge of internal logic code is required. Mostly done by developers. Black box testing: To do black box testing , we should know the functionality of application,logic code is not required. This testing is done by testers. Block box or system testing : testing the application without knowledge of underline code of the application. it is done by the testers. White box testing or unit testing : To do white box testing knowledge of internal logic code is required. Mostly done by developers. Black box testing: To do black box testing , we should know the functionality of application,logic code is not required. This testing is done by testers. Block box or system testing : testing the application without knowledge of underline code of the application. it is done by the testers. Q2. Define software testing? Why it is important ? Ans: Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test.[1] Software testing also provides an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not limited to, the process of executing a program or application with the intent of finding software bugs (errors or other defects). Q3. State Pareto principle applies to software testing. Ans: Pareto Principle – It states that 80 percent of the uncovered errors in testing is from the 20 percent of the software components. Q4. Explain different types of testing. Ans: Software Testing Types: Black box testing – Internal system design is not considered in this type of testing. Tests are based on requirements and functionality. White box testing – This testing is based on knowledge of the internal logic of an application’s code. Also known as Glass box Testing. Internal software and code working should be known for this type of testing. Tests are based on coverage of code statements, branches, paths, conditions. Unit testing – Testing of individual software components or modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. may require developing test driver modules or test harnesses. Incremental integration testing – Bottom up approach for testing i.e continuous testing of an application as new functionality is added; Application functionality and modules should be independent enough to test separately. done by programmers or by testers. Integration testing – Testing of integrated modules to verify combined functionality after integration. Modules are typically code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server and distributed systems. Functional testing – This type of testing ignores the internal parts and focus on the output is as per requirement or not. Black-box type testing geared to functional requirements of an application. System testing – Entire system is tested as per the requirements. Black-box type testing that is based on overall requirements specifications, covers all combined parts of a system. End-to-end testing – Similar to system testing, involves testing of a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate. Sanity testing - Testing to determine if a new software version is performing well enough to accept it for a major testing effort. If application is crashing for initial use then system is not stable enough for further testing and build or application is assigned to fix. Regression testing – Testing the application as a whole for the modification in any module or functionality. Difficult to cover all the system in regression testing so typically automation tools are used for these testing types. Acceptance testing -Normally this type of testing is done to verify if system meets the customer specified requirements. User or customer do this testing to determine whether to accept application.

Load testing – Its a performance testing to check system behavior under load. Testing an application under heavy loads, such as testing of a web site under a range of loads to determine at what point the system’s response time degrades or fails. Stress testing – System is stressed beyond its specifications to check how and when it fails. Performed under heavy load like putting large number beyond storage capacity, complex database queries, continuous input to system or database load. Performance testing – Term often used interchangeably with ‘stress’ and ‘load’ testing. To check whether system meets performance requirements. Used different performance and load tools to do this. Usability testing – User-friendliness check. Application flow is tested, Can new user understand the application easily, Proper help documented whenever user stuck at any point. Basically system navigation is checked in this testing. Install/uninstall testing - Tested for full, partial, or upgrade install/uninstall processes on different operating systems under different hardware, software environment. Recovery testing – Testing how well a system recovers from crashes, hardware failures, or other catastrophic problems. Security testing – Can system be penetrated by any hacking way. Testing how well the system protects against unauthorized internal or external access. Checked if system, database is safe from external attacks. Compatibility testing – Testing how well software performs in a particular hardware/software/operating system/network environment and different combination s of above. Comparison testing – Comparison of product strengths and weaknesses with previous versions or other similar products. Alpha testing – In house virtual user environment can be created for this type of testing. Testing is done at the end of development. Still minor design changes may be made as a result of such testing. Beta testing – Testing typically done by end-users or others. Final testing before releasing application for commercial purpose. Q5. Difference between top-down integration and bottom-up integration. Ans:

Criteria Architectural Validation

System Demonstration

Test Implementation

Test Observation

Comparison Top-down testing is better suited than bottom-up testing for early detection of system architecture errors and high-level design errors. Early detection reduces the cost of fixing the errors. A top-down approach to testing allows the organization to quickly gain confidence in a skeletal system that can then be used for demonstration purposes. A bottom-up approach uses drivers at the highest system levels which would likely be more cumbersome to demonstrate. Top-down testing will generally place more of a burden on the development team since meaningful stub behavior will be required for the system to be tested. Stubs can become quite complex in order to provide the necessary behavioral characteristics. Reusable components, on the other hand, provide stable behavior and therefore developers do not need to be quite as creative when creating the drivers that drive those low-level components. Top-down and bottom-up testing are about equal on this criteria. High-level components aren’t necessarily meant to generate observable output and must be made to do so using an artificial environment. Likewise, low-level components may need an artificial environment in order to probe their internal behavior.

Q6. Explain software maintenance with categories. Ans: Software development life cycles involve complex processes using a hierarchy of activities and their documentation and maintenance is the last stage of the software life cycle. Software maintenance includes all activities associated with changing, modifying or altering existing software applications. After the product has been released, the maintenance phase keeps the software up to date with environment changes and changing user requirements. One of the most important criteria in good software development is that all the phases of the software life cycle project should be done in such a way that final product is easily maintainable. Maintenance can only happen efficiently if the earlier phases are done properly. The major problems that can slow down the maintenance process are unstructured code, maintenance programmers having insufficient knowledge of the system, documentation being absent, out of date, insufficient, and software maintenance personnel not having the required attributes for the job. For maintenance to be successful, these problems should be taken care off in the earlier stages of a life cycle project. Maintenance plays an important role in the life cycle of a software product. There are a large number of software projects most of which are unstructured and not well documented. Maintenance can lessen these problems. Maintenance phase is a very expensive phase costing the developers lot of time, effort, and money. Thus, the maintenance phase should be as efficient as possible. There software maintenance phase involves steps like, understanding the design that already exists, the studying the structure of the existing product and finally test and debug the product and make the new changes work properly. As products age it becomes more difficult to keep them updated with new user requirements. There are three categories of software maintenance: Perfective maintenance deals with revise the software according to changes in user requirements, improving documentation, and making the code easier to understand. Perfective maintenance mainly deals with accommodating to new or changed user requirements. Perfective maintenance concerns functional enhancements to the system and activities to increase the system's performance or to enhance its user interface. Adaptive maintenance deals with adapting the software to new environments like new version of OS, system compiler, DB. Corrective maintenance deals with fixing bugs in the code; basically it is fire fighting. It is generally known as the 'traditional maintenance'. Corrective maintenance deals with the repair of faults or defects found. Q7. Write different testing strategies and issues. Ans; Testing Strategies Strategy is a general approach rather than a method of devising particular systems for component tests. Different strategies may be adopted depending on the type of system to be tested and the development process used. The testing strategies are Top-Down Testing Bottom - Up Testing Thread Testing Stress Testing Back- to Back Testing 1. Top-down testing Where testing starts with the most abstract component and works downwards. 2. Bottom-up testing Where testing starts with the fundamental components and works upwards. 3. Thread testing Which is used for systems with multiple processes where the processing of a transaction threads its way through these processes. 4. Stress testing

Which relies on stressing the system by going beyond its specified limits and hence testing how well the system can cope with over-load situations. 5. Back-to-back testing Which is used when versions of a system are available. The systems are tested together and their outputs are compared. 6. Performance testing. This is used to test the run-time performance of software. 7. Security testing. This attempts to verify that protection mechanisms built into system will protect it from improper penetration. 8. Recovery testing. This forces software to fail in a variety ways and verifies that recovery is properly performed. the following five issues The software under test doesn't do something that the product specification says it should do. The software under test does something that the product specification says it shouldn’t do. The software under test does something that the product specification does not mention. The software doesn't do something that the product specification doesn’t mention but should do. The software is difficult to understand, hard to use, slow, or – in user’s eye it is not just right. Q8. Explain 1) Regression testing Regression testing means rerunning test cases from existing test suites to build confidence that software changes have no unintended side-effects. The “ideal” process would be to create an extensive test suite and run it after each and every change. Unfortunately, for many projects this is just impossible because test suites are too large, because changes come in too fast, because humans are in the testing loop, because scarce, highly in-demand simulation laboratories are needed, or because testing must be done on many different hardware and OS platforms. Researchers have tried to make regression testing more effective and efficient by developing regression test selection (RTS) techniques, but many problem remain, such as: Unpredictable performance. RTS techniques sometimes save time and money, but they sometimes select most or all of the original test cases. Thus, developers using RTS techniques can find themselves worse off for having done so. Incompatible process assumptions. Testing time is often limited (e.g., must be done overnight). RTS techniques do not consider such constraints and, therefore, can and do select more test cases than can be run. Inappropriate evaluation models. RTS techniques try to maximize average regression testing performance rather than optimize aggregate performance over many testing sessions. However, companies that test frequently might accept less effective, but cheaper individual testing sessions if the system would, nonetheless, be well-tested over some short period of time. These and other issues have not been adequately considered in current research, yet they strongly affect the applicability of proposed regression testing processes. Moreover, we believe that solutions to these problems can be exploited, singly and in combination, to dramatically improve the costs and benefits of the regression testing process. 2) Black box testing Also known as functional testing. Asoftware testing technique whereby the internal workings of the item being tested are not known by the tester. For example, in a black box test on a software design the tester

only knows the inputs and what the expected outcomes should be and not how the program arrives at those outputs. The tester does not ever examine the programmingcode and does not need any further knowledge of the program other than its specifications. Advantages of Black Box Testing · · · · · · · · · · · · more effective on larger units of code than glass box testing tester needs no knowledge of implementation, including specific programming languages tester and programmer are independent of each other tests are done from a user's point of view will help to expose any ambiguities or inconsistencies in the specifications test cases can be designed as soon as the specifications are complete Disadvantages of Black Box Testing only a small number of possible inputs can actually be tested, to test every possible input stream would take nearly forever without clear and concise specifications, test cases are hard to design there may be unnecessary repetition of test inputs if the tester is not informed of test cases the programmer has already tried may leave many program paths untested cannot be directed toward specific segments of code which may be very complex (and therefore more error prone) most testing related research has been directed toward glass box testing 3) Acceptance testing Acceptance testing (also known as user acceptance testing) is a type of testing carried out in order to verify if the product is developed as per the standards and specified criteria and meets all the requirements specified by customer. This type of testing is generally carried out by a user/customer where the product is developed externally by another party. Acceptance testing falls under black box testing methodology where the user is not very much interested in internal working/coding of the system, but evaluates the overall functioning of the system and compares it with the requirements specified by them. User acceptance testing is considered to be one of the most important testing by user before the system is finally delivered or handed over to the end user. Acceptance testing is also known as validation testing, final testing, QA testing, factory acceptance testing and application testing etc. And in software engineering, acceptance testing may be carried out at two different levels; one at the system provider level and another at the end user level (hence called user acceptance testing, field acceptance testing or end-user testing). Acceptance testing in software engineering generally involves execution of number test cases which constitute to a particular functionality based on the requirements specified by the user. During acceptance testing, the system has to pass through or operate in a computing environment that imitates the actual operating environment existing with user. The user may choose to perform the testing in an iterative manner or in the form of a set of varying parameters (for example: missile guidance software can be tested under varying payload, different weather conditions etc.). The outcome of the acceptance testing can be termed as success or failure based on the critical operating conditions the system passes through successfully/unsuccessfully and the user’s final evaluation of the system. The test cases and test criterion in acceptance testing are generally created by end user and cannot be achieved without business scenario criteria input by user. This type of testing and test case creation involves most experienced people from both sides (developers and users) like business analysts, specialized testers, developers, end users etc. Process involved in Acceptance Testing

1. 2. 3. 4. 5.

Test cases are created with the help of business analysts, business customers (end users), developers, test specialists etc. Test cases suites are run against the input data provided by the user and for the number of iterations that the customer sets as base/minimum required test runs. The outputs of the test cases run are evaluated against the criterion/requirements specified by user. Depending upon the outcome if it is as desired by the user or consistent over the number of test suites run or non conclusive, user may call it successful/unsuccessful or suggest some more test case runs. Based on the outcome of the test runs, the system may get rejected or accepted by the user with or without any specific condition.

4) Alpha – beta testing Alpha Test In software development, your alpha test, will be a test among yourselves (the teams) to confirm that your product works. Originally, the term alpha test meant the first phase of testing in a software development process. The first phase includes unit testing, component testing, and system testing. During this time you will compress files, edit for misspelled words and unclear directions, broken links, and sync audio and video. You will also test your product on the lowest common denominator machines to make sure download times are acceptable and preloaders work. Beta Test In software development, a beta test is the second phase of software testing in which a sampling of the intended audience tries the product out. Beta testing can be considered "pre-release testing." Beta test versions of software are now distributed to curriculum specialists and teachers to give the program a "real-world" test and partly to provide a preview of the next release. 5) Smoke testing Smoke testing originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch fire and smoke. In software industry, smoke testing is a shallow and wide approach whereby all areas of the application without getting into too deep, is tested. A smoke test is scripted, either using a written set of tests or an automated test A Smoke test is designed to touch every part of the application in a cursory way. It’s shallow and wide. Smoke testing is conducted to ensure whether the most crucial functions of a program are working, but not bothering with finer details. (Such as build verification). Smoke testing is normal health check up to a build of an application before taking it to testing in depth. Typical characteristics of Smoke Testing:    It exercises the entire system from end-to-end. It is not exhaustive but should be capable of exposing major problems. It ensures that the major functionality is working and the build is stable enough for further testing thoroughly. Advantages of Smoke Testing:    Reduced Integration Risk : Since smoke testing is carried out the integration problems are uncovered at a much earlier stage than late in the cycle. Finds Major Problems: A good designed smoke test can increase the probability of finding a major problem when a software is built early in the cycle. Thus you catch bugs earlier in the cycle. Can save time and cost – If a major problem is detected at the stage when the software is ready built, it can save huge time and cost if the same error was discovered late in the cycle. Q9. Define test cases. Explain basic path testing.

Ans: A test case in software engineering is a set of conditions or variables under which a tester will determine whether an application or software system is working correctly or not. The mechanism for determining whether a software program or system has passed or failed such a test is known as a test oracle. In some settings, an oracle could be a requirement or use case, while in others it could be a heuristic. It may take many test cases to determine that a software program or system is considered sufficiently scrutinized to be released. Test cases are often referred to as test scripts, particularly when written. Written test cases are usually collected into test suites. Basis Path Testing Basis path testing is a white-box technique. It allows the design and definition of a basis set of execution paths. The test cases created from the basis set allow the program to be executed in such a way as to examine each possible path through the program by executing each statement at least once. To be able to determine the different program paths, the engineer needs a representation of the logical flow of control. The control structure can be illustrated by a flow graph. A flow graph can be used to represent any procedural design. Next a metric can be used to determine the number of independent paths. It is called cyclomatic complexity and it provides the number of test cases that have to be designed. This insures coverage of all program statements. Q10. Explain data flow mechanism. Ans: A data flow diagram (DFD) is a significant modeling technique for analyzing and constructing information processes. DFD literally means an illustration that explains the course or movement of information in a process. DFD illustrates this flow of information in a process based on the inputs and outputs. A DFD can be referred to as a Process Model. Additionally, a DFD can be utilized to visualize data processing or a structured design. A DFD illustrates technical or business processes with the help of the external data stored, the data flowing from a process to another, and the results. A designer usually draws a context-level DFD showing the relationship between the entities inside and outside of a system as one single step. This basic DFD can be then disintegrated to a lower level diagram demonstrating smaller steps exhibiting details of the system that is being modelled. Numerous levels may be required to explain a complicated system.

Q11. What do you mean by integration testing ? explain types

Ans: Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once. Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis. You can do integration testing in a variety of ways but the following are three common strategies: The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality. The bottom-up approach requires the lowest-level units be tested and integrated first. These units are frequently referred to as utility modules. By using this approach, utility modules are tested early in the development process and the need for stubs is minimized. The downside, however, is that the need for drivers complicates test management and high-level logic and data flow are tested late. Like the top-down approach, the bottom-up approach also provides poor support for early release of limited functionality. The third approach, sometimes referred to as the umbrella approach, requires testing along functional data and control-flow paths. First, the inputs for functions are integrated in the bottom-up pattern discussed above. The outputs for each function are then integrated in the topdown manner. The primary advantage of this approach is the degree of support for early release of limited functionality. It also helps minimize the need for stubs and drivers. The potential weaknesses of this approach are significant, however, in that it can be less systematic than the other two approaches, leading to the need for more regression testing. Types Top- down Integration testing A top-down approach (also known as step-wise design) is essentially the breaking down of a system to gain insight into its compositional sub-systems. In a top-down approach an overview of the system is formulated, specifying but not detailing any first-level subsystems. Each subsystem is then refined in yet greater detail, sometimes in many additional subsystem levels, until the entire specification is reduced to base elements. A top-down model is often specified with the assistance of "black boxes", these make it easier to manipulate. However, black boxes may fail to elucidate elementary mechanisms or be detailed enough to realistically validate the model. Bottom – up Integration testing A bottom-up approach is the piecing together of systems to give rise to grander systems, thus making the original systems sub-systems of the emergent system. In a bottom-up approach the individual base elements of the system are first specified in great detail. These elements are then linked together to form larger subsystems, which then in turn are linked, sometimes in many levels, until a complete top-level system is formed. This strategy often resembles a "seed" model, whereby the beginnings are small but eventually grow in complexity and completeness

Unit 5
Q1. Define risk management. Ans: Risk management is a systematic approach to minimizing an organization's exposure to risk. A risk management system includes various policies, procedures and practices that work in unison to identify, analyze, evaluate, address and monitor risk. Risk management information is used along with other corporate information, such as feasibility, to arrive at a risk management decision. Transferring risk to another party, lessening the negative affect of risk and avoiding risk altogether are considered risk management strategies. Q2. What is measure and measurement? Ans: Software measures are used to quantify software products, software development resources, and the software development process. There are many characteristics of software and software projects that can be measured, such as size, complexity, reliability, quality, adherence to process, and profitability. Measurement of both the product and development processes has long been recognized as a critical activity for successful software development. Good measurement practices and data enable realistic project planning, timely monitoring of project progress and status, identification of project risks, and effective process improvement. Appropriate measures and indicators of software artifacts such as requirements, designs, and source code can be analyzed to diagnose problems and identify solutions during project execution and reduce defects, rework (effort, resources, etc.), and cycle time. Q4. What do you mean by software complexity? Ans: Complexity is everywhere in the software life cycle: requirements, analysis, design, and of course, implementation. Complexity is usually an undesired property of software because complexity makes software harder to read and understand, and therefore harder to change; also, it is believed to be one cause of the presence of defects. Of all the artifacts produced in a software project, source code is the easiest option to measure complexity. Q5. explain COCOMO model Ans: Introduction: The structure of empirical estimation models is a formula, derived from data collected from past software projects, that uses software size to estimate effort. Size, itself, is an estimate, described as either lines of code (LOC) or function points (FP). No estimation model is appropriate for all development environments, development processes, or application types. Models must be customised (values in the formula must be altered) so that results from the model agree with the data from the particular environment. The typical formula of estimation models is: where; E = a + b(S)c

E represents effort, in person months, S is the size of the software development, in LOC or FP, and, a, b, and c are values derived from data.

The relationship seen between development effort and software size is generally:

E

S This graph demonstrates that the amount of effort accelerates as size increases, i.e., the value c in the typical formula above is greater than 1.

COCOMO: When Barry Boehm wrote 'Software Engineering Economics', published in 1981, he introduced an empirical effort estimation model (COCOMO - COnstructive COst MOdel) that is still referenced by the software engineering community. The original COCOMO model was a set of models; 3 development modes (organic, semi-detached, and embedded) and 3 levels (basic, intermediate, and advanced). COCOMO model levels: Basic - predicted software size (lines of code) was used to estimate development effort. Intermediate - predicted software size (lines of code), plus a set of 15 subjectively assessed 'cost drivers' was used to estimate development effort. Advanced - on top of the intermediate model, the advanced model allows phase-based cost driver adjustments and some adjustments at the module, component, and system level. COCOMO development modes: Organic - small relatively small, simple software projects in which small teams with good application experience work to a set of flexible requirements. Embedded - the software project has tight software, hardware and operational constraints. Semi-detached - an intermediate (in size and complexity) software project in which teams with mixed experience levels must meet a mix of rigid and less than rigid requirements.1 COCOMO model: The general formula of the basic COCOMO model is: Where: E = a(S)b E represents effort in person-months, S is the size of the software development in KLOC and, a and b are values dependent on the development mode, organic semi-detached embedded a = 2.4 a = 3.0 a = 3.6 b = 1.05 b = 1.12 b = 1.20

development mode:

The intermediate and advanced COCOMO models incorporate 15 'cost drivers'. These 'drivers' multiply the effort derived for the basic COCOMO model. The importance of each driver is assessed and the corresponding value multiplied into the COCOMO equation, which becomes: E = a(S)b x product(cost drivers) Q6. Explain Delphi model. Ans: Q7. Discuss characteristics of software Engg. Ans: To properly satisfy the basic goals, an SRS should have certain properties and should contain different types of requirements. Some of the desirable characteristics of an SRS are : 1. Correct

2. Complete 3. Unambiguous 4. Verifiable 5. Consistent 6. Ranked for importance and/or stability An SRS is correct if every requirement included in the SRS represents something required in the final system. It is complete if everything the software is supposed to do and the responses of the software to all classes of input data are specified in the SRS. It is unambiguous if and only if every requirement stated has one and only one interpretation. Requirements are often written in natural language, which is inherently ambiguous. If the requirements are specified in a natural language, the SRS writer has to be especially careful to ensure that there are no ambiguities. An SRS is verifiable if and only if every stated requirement is verifiable. A requirement is verifiable if there exists some cost-effective process that can check whether the final software meets that requirement. It is consistent if there is no requirement that conflicts with another. Terminology can cause inconsistencies; for example, different requirements may use different terms to refer to the same object. There may be logical or temporal conflict between requirements that causes inconsistencies. This occurs if the SRS contains two or together by any software system. For example, suppose a requirement states that an event e is to occur before another event f. But then another set of requirements states (directly or indirectly by transitivity) that event f should occur before event e.Inconsistencies in an SRS can reflect some major problems. Generally, all the requirements for software are not of equal importance. Some are critical, others are important but not critical, and there are some which are desirable but not very important. Similarly, some requirements are “core” requirements which are not likely to change as time passes, while others are more dependent on time. Some provide more value to the users than others. An SRS is ranked for importance and/or stability if for each requirement the importance and the stability of the requirement are indicated. Stability of a requirement reflects the chances of it changing in the future. It can be reflected in terms of the expected change volume. This understanding of value each requirement provides is essential for iterative development—selection of requirements for an iteration is based on this evaluation. Of all these characteristics, completeness is perhaps the most important and also the most difficult property to establish. One of the most common defects in requirements specification is incompleteness. Missing requirements necessitate additions and modifications to the requirements later in the development cycle, which are often expensive to incorporate. Incompleteness is also a major source of disagreement between the client and the supplier. Some, however, believe that completeness in all details may not be desirable. The pursuit of completeness can lead to specifying details and assumptions that may be commonly understood. (For example, specifying in detail what a common operation like add a record means.) And specifying these details can result in a large requirements document, which has its own problems including making validation harder. On the other hand, if too few details are given, the chances of developer’s understanding being different from others’ increases, which can lead to defects in the software. For completeness, a reasonable goal is to have “sufficient detail” for the project at hand. For example, if the waterfall model is to be followed in the project, it is better to have detailed specifications so the need for changes is minimized. On the other hand, for iterative development, as feedback is possible and opportunity for change is also there, the specification can be less detailed. And if an agile approach is being followed, then completeness should be sought only for top-level requirements, as details may not be required in written form, and are elicited when the requirement is being implemented. Together the performance and interface requirements and design constraints can be called nonfunctional requirements. Q8. Difference between milestones and deliverable. Ans: MILESTONES AND DELIVERABLES: Managers need information. As software is intangible, this information can only be provided

as document that describes the state of the software being developed. Without this information, it is important tojudge progress and cost estimates and schedules cannot be updated. When planning a project, a series of milestones should be established where a milestone is an end-point of a software process activity. At each milestone, there should be a formal output, such as a report, they can be represented to management. Milestone reports don't need large documents. They may simply be a short report of achievements in a project activity. Milestones should represent the end of a distinct, logical stage in the project. Indefinite milestones such as "Coding 80% complete" which are impossible to validate are useless for project management. A "deliverable" is a project result that is delivered to the customer. It is usually delivered at the end of some major project phase such as specification, design, etc. Deliverables are usually milestones but milestones need not to be deliverables. Milestones may be internal project results that are used by the major project manager to check project progress but which are not delivered to the customers. To establish milestones, the software process must be broken down into basic activities with associated outputs.