CS6403 SOFTWARE ENGINEERING UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT

Transcription

1 CS6403 SOFTWARE ENGINEERING UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT SYLLABUS: Introduction to Software Engineering, Software Process, Perspective and Specialized Process Models Software Project Management: Estimation LOC and FP Based Estimation, COCOMO Model Project Scheduling Scheduling, Earned Value Analysis - Risk Management. COURSE OBJECTIVE: Able to compare different process models. Able to identify the key activities in managing a software project. PART-A 1. Define software engineering. (April/May 2011) Software engineering is defined as the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering software. 2. What are the objectives/goals of Software engineering? (April/May 2011) To improve quality of software products To increase customer satisfaction To increase productivity To increase job satisfaction 3. What are the characteristics of software? Software is engineered not manufactured Software does not wear out Most of the software is custom built rather being assembled form components 4. List out the activities of linear sequential model. i. System/Information engineering modeling ii. Requirement Analysis iii. Design iv. Coding v. Testing vi. Implementation & Maintenance 5. Mention the drawbacks of RAD Model. i. It is useful only for larger projects. ii. It is not appropriate when technical risks are high. iii. The requirements may not converge in RAD Model. 6. Define Software Life Cycle. Requirement Analysis Design Coding Testing II Year / IV Sem 1

2 Implementation & Maintenance 7. Write any two software engineering challenges? (May/June 07) Trust challenges Heterogeneity challenge Delivery time s challenge 8. Define the term process in software engineering? (May/June 07) (May/June2012) Software process is defines as the series of steps that are followed to build a product or system. 9. What is a software process? 1 A set of activities whose goal is the development or evolution of software 2 Generic activities in all software processes are: Specification - what the system should do and its development constraints Development - production of the software system Validation - checking that the software is what the customer wants Evolution - changing the software in response to changing demands 10. Distinguish between verification and validation. (April/may2011)(May/June 2014) Verification represents the set of activities that are carried out to confirm that the software correctly implements the specific functionality. Validation represents the set of activities that ensure that the software that has been built is satisfying the customer requirements. 11. Define Software Architecture. (Apr/May 08) It serves as a design plan that is used to negotiate system requirements and as a means of structuring discussions with the client, developers, and managers. It is a essential tool for complexity management. It hides details and allows the designers to focus on the key system abstractions. 12. State the benefits of waterfall life cycle model for software development. (Apr/May 08) 1. Simple to understand 2. Each phase of development proceeds sequentially. 3. Allows managerial control where a schedule with deadlines is set for each stage of development. 4. Helps in controlling schedules, budgets and documentation. 13. What are the fundamental activities of software process? (Nov/Dec 2008) Specification Design and implementation Validation Evolution 14. What is software process model? A process model is defined as a framework containing the processes, activities and tasks involved in the development, operation and maintenance of a software product, spanning the life of the system from the definition of its requirements to the termination of its use. II Year / IV Sem 2

3 15. What is Software? Software is nothing but a collection of computer programs that are related documents that are indented to provide desired features, functionalities and better performance. 16. What are the drawbacks of spiral model? i. It is based on customer communication. If the communication is not proper then the software product that gets developed will not be upto the mark. ii. It demands considerable risk assessment.if the risk assessment is done properly then only the successful product can be obtained. 17. Name the Evolutionary process Models. i. Incremental model ii. Spiral model iii. WIN-WIN spiral model iv. Concurrent Development 18. What are the functions of data architecture? It provides the information needed for a business function. Identify the data objects and their relationship. Eg: Customer Attributes: Company name Contact information Product information Past purchase 19. Define Verification &Validation. Verification: The set of activities that ensure that software correctly implements a specific function. Validation: The set of activities that ensure that the software has been built is traceable to customer requirements. 20. Give two reason why system engineers must understand the environment of a system (Nov/Dec 2012) The reason for the existence of a system is to make some changes in its environment. The functioning of a system can be very difficult to predict. 21. Distinguish between spiral model and win win spiral model. (May/June 2013) Spiral: Addresses Risk at every stage & let the stakeholders determine the outcome. Win/Win Seeks ways to provide customer feedback through anchor points, manages risk for management, and provides win conditions for developers. 22. What is software project Management? (NOV -2009) The software project management is the art and science of planning and leading software projects. It is a sub discipline of project management in which software project are planned monitored and controlled. II Year / IV Sem 3

4 23. What is LOC based estimation? Lines of code (LOC), is a software metric used to measure the size of a computer program by counting the number of lines in the text of the program's source code. SLOC is typically used to predict the amount of effort that will be required to develop a program, as well as to estimate programming productivity or maintainability once the software is produced. 24. What is FP based estimation? Function point metrics provide a standardized method for measuring the various functions of a software application. Function point metrics, measure functionality from the users point of view, that is, on the basis of what the user requests and receives in return 25. What is COCOMO model? The Constructive Cost Model (COCOMO) is an algorithmic software cost estimation model developed by Barry W. Boehm. The model uses a basic regression formula with parameters that are derived from historical project data and current as well as future project characteristics. 26. What is Earned Value Analysis? It is a quantitative technique using which we can evaluate the performance of project and predict the final results, for this we compare present progress and cost incurred to planned estimations. It is the most comprehensive trend analysis technique. 27. What is Software project scheduling? Software project scheduling distributes estimated effort across the planned project duration by allocating the effort to specific tasks. 28. Write the process framework and umbrella activities. (Apr / May 2015) Software process models can be prescriptive or agile, complex or simple, all-encompassing or targeted, but in every case, five key activities must occur. The framework activities are applicable to all projects and all application domains, and they are a template for every process model. Software project tracking and control. Risk management. Software Quality Assurance. Formal Technical Reviews. Software Configuration Management. Work product preparation and production. Reusability management. Measurement. 29. State the advantages and disadvantages in LOC based cost estimation. (Apr / May 2015) Advantages: A measure of the rate at which individual engineers involved in software development produce software and associated documentation. Not quality-oriented although quality assurance is a factor in productivity assessment. Essentially, we want to measure useful functionality produced per time unit. Disadvantages: Estimating the size of the measure (e.g. how many function points). II Year / IV Sem 4

5 Estimating the total number of programmer months that have elapsed. Estimating contractor productivity (e.g. documentation team) and incorporating this estimate in overall estimate. PART-B 1. What are the differences between system engineering & software engineering? State and explain the stages that distinguish the two. (April/May 2008)(R) 2. What are the necessities of life cycle model? Elaborate on the various issues of software life cycle. (April/May 2008)(April/May 2011)(R) 3. Explain in detail the following software process models with a neat diagram. (April/May 2008) i. Incremental Process Model.(U) ii. Evolutionary Process Model 4. Explain the spiral model. What are the task regions in the spiral model? How does 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 deadline?(u) 5. Explain the system engineering hierarchy. What does a system engineering model accomplish? What are the restraining factors to construct a system model? (May/June 2007)(Nov/Dec 2009)(U) 6. Explain the linear software life cycle model with suitable illustration. Bring out the demerits of this model. (May/June 2007)(U) 7. For each of the types of process model, identify the types of project suitable to implement. (May/June 2007)(U) 8. Distinguish between verification and validation process. (May/June 2007)(U) 9. Explain Software Life Cycle.List all life cycle model and explain spiral model with neat diagram(may/june 2012)(Nov/Dec 2008)(U) 10. Bring out clearly the salient features of waterfall model and spiral model. What are the specific advantages and disadvantages of these two process models?(nov/dec 2010)(R) 11. Describe waterfall, incremental, iterative waterfall, spiral model based on SLCS and compare. (Nov/Dec 2012)(U) 12. Explain Project Scheduling?(U) 13. Explain FP based Estimation & LOC based Estimation?(U) 14. Explain Risk Management in detail?(u) 15. Discuss in detail about two evolutionary process models. (May/June 2014)(U) 16. Discuss about the classical waterfall process model. (May/June 2014)(U) 17. Explain the prototype paradigm in process models. (May/June 2014)(U) 18. Neatly explain the following process models and write their advantages and disadvantages. (Apr / May 2015)(U) i. Spiral model ii. Rapid Application Development model 19. Discuss about the COCOMO models (Basic, Intermediate and Detailed) for cost estimation. (Apr / May 2015)(U) 20. Discuss the prototyping model. What is the effect of designing a prototype on the overall cost of the software project? (Apr / May 2016)(U) 21. Describe the types of situations where iterative enhancement model might lead to difficulties. (Apr / May 2016)(U) 22. Elucidate the key features of the software process models with suitable examples. (Apr / May 2016) II Year / IV Sem 5

6 23. What is the role of user participation in the selection of a life cycle model? (Apr / May 2016)(U) COURSE OUTCOME: Students can able to identify the key activities in managing a software project. UNIT II REQUIREMENTS ANALYSIS AND SPECIFICATION SYLLABUS: Software Requirements: Functional and Non-Functional, User requirements, System requirements, Software Requirements Document Requirement Engineering Process: Feasibility Studies, Requirements elicitation and analysis, requirements validation, requirements management- Classical analysis: Structured system Analysis, Petri Nets- Data Dictionary. COURSE OBJECTIVE: Ability to do requirements engineering and Analysis Modeling. PART-A 1. What is functional requirement? (April/May2011)(Nov/Dec 2010) These are statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. 2. What is nonfunctional requirement? (April/May 2011)(May/June2012)(Nov/Dec 2010) These are constraints on the services or functions offered by the system. They include timing constraints, constraints on the development process and standards. Non-functional requirements often apply to the system as a whole. They do not usually just apply to individual system features or services. 3. Define requirement engineering. Requirement engineering is the process of establishing the services that the customer requires from the system and the constraints under which it operates and is developed. The overall process includes four high-level requirements engineering sub-processes. These are concerned with assessing whether the system is useful to the business (feasibility study); discovering requirements (elicitation and analysis); converting these requirements into some standard form (specification); and checking that the requirements actually define the system that the customer wants (validation) 4. What is System Requirements? System requirements are expanded versions of the user requirements that are used by software engineers as the starting point for the system design. They add detail and explain how the user requirements should be provided by the system. They may be used as part of the contract for the implementation of the system and should therefore be a complete and consistent specification of the whole system. 5. Mention the notation for requirement specification. Structured natural language: Use standard form or Templates. Design description language: Programming language is used. Graphical notation: Text annotations are used. Mathematical Specifications: Based on finite state machines or sets. II Year / IV Sem 6

7 6. What is the major distinction between user requirements and system requirements? (Apr/May 08) It is essential to write user requirements in a language that non-specialists can understand but to write system requirements in a more specialized notation. System requirements are expanded versions of the user requirements that are used by software engineers as the starting point for the system design. They add detail and explain how the user requirements should be provided by the system. They may be used as part of the contract for the implementation of the system and should therefore be a complete and consistent specification of the whole system. 7. Which style of prototyping is most appropriate when the requirements are not Well-understand? (Apr/May 08) Throw-away prototyping A prototype which is usually a practical implementation of the system is produced to help discover requirements problems and then discarded. The system is then developed using some other development process. The objective of throw-away prototyping is to validate or derive the system requirements. The prototyping process starts with those requirements which are poorly understood. Used to reduce requirements risk The prototype is developed from an initial specification, delivered for experiment then discarded The throw-away prototype should NOT be considered as a final system 8. Identify ambiguities or omissions in the functional requirements. What questions would you ask to clarify these functional requirements? (Apr/May 08) Is the requirement complete? (All facilities are included?) Is the requirement consistent? (Conflicts) 9. What are the problems make elicitation difficult? (Apr/May 08) Stakeholders often don't know what they want from the computer system except in the most general terms. Stakeholders naturally express requirements in their own terms and with implicit knowledge of their own work Different stakeholders have different requirements, which they may express in different ways Political factors may influence the requirements of the system The economic and business environment in which the analysis takes place is dynamic. 10. Why is it so difficult to gain a clear understanding of what the customer wants? (Nov/Dec 07) Stakeholders often don't know what they want from the computer system except in the most general terms. Stakeholders naturally express requirements in their own terms and with implicit knowledge of their own work Different stakeholders have different requirements, which they may express in different ways II Year / IV Sem 7

8 11. List out the elements of analysis model. (May/June 07) Data Dictionary Entity Relationship Diagram Data Flow Diagram State Transition Diagram Control Specification Process specification 12. What are the characteristics of SRS? (May/June 2016) i. Correct The SRS should be made up to date when appropriate requirements are identified. ii. Unambiguous When the requirements are correctly understood then only it is possible to write unambiguous software. iii. Complete To make SRS complete, it should be specified what a software designer wants to create software. iv. Consistent It should be consistent with reference to the functionalities identified. v. Specific The requirements should be mentioned specifically. vi. Traceable What is the need for mentioned requirement? This should be correctly identified. 13. What are the objectives of Analysis Modeling? i.to describe what the customer requires. ii. To establish a basis for the creation of software design. iii. To devise a set of valid requirements after which the software can be built. 14. What is data modeling? Data modeling is the basic step in the analysis modeling. In data modeling the data objects are examined independently of processing. The data model represents how data are related with one another. 15. What is the cardinality in data modeling? Cardinality in data modeling, cardinality specifies how the number of occurrences of one object is related to the number of occurrences of another object. 16. Define data dictionary. (May/June 2013) The data dictionary can be defined as an organized collection of all the data elements of the system with precise and rigorous definitions so that user and system analyst will have a common understanding of inputs, outputs, components of stores and intermediate calculations. 17. Define software prototyping. (April/May 2011) (Nov/Dec 2010) Software prototyping is defined as a rapid software development for validating the requirements. Software prototyping is a method of creating a model for the software product. This is developed based on the currently known requirements. Software prototyping helps in the better understanding of the required system. It is applied for complicated and large systems. In software prototyping, the customer defines a set of general objectives for the software, but does not identify the real input, processing and output requirements. The following are the benefits Misunderstandings between software users and developers are exposed II Year / IV Sem 8

9 Missing services may be detected and confusing services may be identified A working system is available early in the process The prototype may serve as a basis for deriving a system specification The system can support user training and system testing Improved system usability Closer match to the system needed Improved design quality Improved maintainability Reduced overall development effort 18. What are the advantages of software prototyping? i. Prototype serves as a basis for deriving system specification. ii. Design quality can be improved. iii. System can be maintained easily. iv. Development efforts may get reduced. v. System usability can be improved. 19. What are the different kinds of software prototyping? i. Evolutionary prototyping In this approach of system development, the initial prototype is prepared and it is then refined through number of stages to final stage. ii. Throw-away prototyping Using this approach a rough practical implementation of the system is produced. The requirement problems can be identified from this implementation. It is then discarded. System is then developed using some different engineering paradigm. 20. What are the various rapid prototyping approaches? i. Dynamic high level language development. ii. Database programming. iv. Component and application assembly. 21. What is data object? What are its attributes? Data object is a representation of almost any composite information that must be understood by software. It is a collection of attributes that act as an aspect, characteristic, quality, or descriptor of the object. Attributes are the one, which defines the properties of data object and take on one of three different characteristics 1)name of an instance 2)describe the instance 3) make reference to another to instance in another table. 22. What is meant by structured analysis? It considers the data and the process that transform the data as separate entities. Data objects are modeled in a way that defines their attribute and relationships. Process that manipulates data and objects are modeled in a manner that shows how they transform data as data objects flow through the system. 23. Define Modality. Modality indicates whether or not a particular data object must participate in the relationship. It is 0 if there are no relationship explicitly or optional. It is 1 if an occurrence of the relationship is mandatory. II Year / IV Sem 9

10 24. Define Behavioral Modeling. It indicates how the software will respond to external events or stimuli. To create the model, the analyst must perform the following steps Evaluate all use cases Identify the events that drive the interaction sequence Create a sequence for each use case Build a state diagram for the system Review the behavioral model to verify the accuracy and consistency 25. What is meant by Information flow continuity? When we refine a fundamental model for a system, the information flow continuity must be maintained.ie, input & output to each refinement must remain the same 26. What is meant by Data Dictionary? The data dictionary can be defined as an organized collection of all the data elements of the system with precise and rigorous definitions so that user and system analyst will have a common understanding of inputs, outputs, components of stores and intermediate calculations 27. What is meant by Throw away Prototyping? Throw-away prototyping Using this approach a rough practical implementation of the system is produced. Giving the user a system which is incomplete and then modifying and augmenting it as the user requirements become clear. The objective is to validate or derive the system requirements. Start with those requirements that are not well understood since you need to find more about them. It is then discarded. System is then developed using some different engineering paradigm. 28. Define DFD. Data Flow Diagram depicts the information flow and the transforms that are applied on the data as it moves from input to output. Level0 DFD is called as fundamental system model or context model. In the context model the entire software system is represented by a single bubble with input and output indicated by incoming and outgoing arrows. 29. State Entity/relationship Diagram. The object/relationship pair is the cornerstone of the data model. These pairs can be represented graphically using the entity/relationship diagram. The ERD was originally proposed by Peter Chen for the design of relational database systems and has been extended by others. A set of primary components is identified for the ERD: data objects, attributes, relationships, and various type indicators. The primary purpose of the ERD is to represent data objects and their relationships. Data objects are represented by a labeled rectangle. Relationships are indicated with a labeled line connecting objects. In some variations of the ERD, the connecting line contains a diamond that is labeled with the relationship. Connections between data objects and relationships are established using a variety of special symbols that indicate cardinality and modality. 30. What is the purpose of Domain Analysis? The goal of Domain analysis is to find or create those analysis classes and / or common functions and features that are broadly applicable, so that they may be reused. The analyst should discover II Year / IV Sem 10

11 and define reusable analysis patterns, analysis classes, and related information that may be used by many people working on similar but necessarily the same application. 31. What is meant by System Requirements? Set out the system services and constraints in detail. Serves as a contract between the system buyer & the system developer. 32. What are the types of Software system requirements? Functional requirements: Services the system should provide. Non-functional requirements: Constraints on the services. Domain requirements: reflect characteristics of the domain. 33. Write down the functional requirement for a Library management system. The user should able to search either all of the initial set of databases or select a subset of databases or select subset from it. The system shall provide appropriate viewers for the user to read documents in the document store. Every order shall be allocated a unique identifier. 34. Write down the SRC for Add a node? Function Add node Description Adds a node to an existing design. Inputs Node type, Node position, Design Identifier Source Node type, Node position user. Design identifier database Output Design identifier Precondition The design is open & displayed on the user s screen Side effects None 35. State the primary objectives of analysis Model. To describe what the customer requires To establish a basis for the creation of a software design To define a set of requirements that can be validated once the software is built. 36. What does data dictionary contains? Name: The primary name of the data. Alias: other names used Where-used/How-used: A listing of processes that use the data or control item. Content description: A notation for representing the content Supplementary information: Other information like restrictions, limitations etc. 37. Write down the Data dictionary for the data item Telephone Number. Names: Telephone number Aliases: none Where used/how used: assess against set-up Description Telephone number = [local number long distance number] Local number = prefix + access number Long distance number = 1 + area code + local number II Year / IV Sem 11

12 Area code = [ ] Prefix = * a three digit number that never starts with 0 or 1* 38. What are the advantages of evolutionary prototyping? i. Fast delivery of the working system. ii. User is involved while developing the system. iii. More useful system can be delivered. iv. Specification, design and implementation work in co-ordinated manner. 39. What are the different types of traceability in software engineering? Source traceability These are basically the links from requirement to stakeholders who propose these requirements. Requirements traceability These are links between dependent requirements. Design traceability These are links from requirements to design. 40. Distinguish between inceptions, elicitation, and elaboration with reference to requirements. (Nov/Dec 2012) During inception, the requirements engineer asks a set of questions to establish A basic understanding of the problem The people who want a solution The nature of the solution that is desired Elicitation may be accomplished through two activities Collaborative requirements gathering Quality function deployment During elaboration, the software engineer takes the information obtained during inception and elicitation and begins to expand and refine it. Elaboration focuses on developing a refined technical model of software functions, features, and constraints. 41. What is Petri Net? Petri net is a directed bipartite graph, in which the nodes represent transitions (i.e. events that may occur, signified by bars) and places (i.e. conditions, signified by circles). The directed arcs describe which places are pre- and/or post conditions for which transitions (signified by arrows). 42. What is the need for feasibility analysis? (Apr / May 2015) The purpose of feasibility study is not to solve the problem, but to determine whether the problem is worth solving. This helps to decide whether to proceed with the project or not.the technical feasibility study compares the level of technology available in the software development firm and the level of technology required for the development of the product.here the level of technology consists of the programming language, the hardware resources, Other software tools etc. 43. How are requirements validated? (APR/MAY 2015) It is desirable to detect errors in the requirements before the design and development of the software begins. To check all the issues related to requirements, requirements validation is performed. II Year / IV Sem 12

13 PART-B 1. Discuss in details about the elements in data modeling. (May/June 07)(C) 2. Explain the various prototyping methods and tools used for requirement analysis. (May/June07)(U) 3. With a suitable example explain about the application of use cases in deriving the scenarios. (May/June 07)(Ap) 4. Explain software prototyping. What are the various prototyping methods and tolls? (Nov/Dec 07)(May/June 2012)(April/May 2011)(R) 5. Explain with example diagram the functional and behavioral modeling. How do we model the software s reaction to some external event? (Nov/Dec 07)(Ap) 6. State and explain the requirements engineering tasks in detail. (Apr/May 08)(April/May 2011)(Nov/Dec 2010)(Ap) 7. Describe the primary differences between structured analyses and object oriented analysis. (Nov/Dec 07)(U) 8. Write a detailed note on scenario based modeling. (Nov/Dec 07)(R) 9. Why is traceability an important aspect of requirements management? Why context system models are useful for requirement validation? (Apr/May 07)(U) 10. Describe how Software requirements are documented? State the importance of documentation.(u) 11. Differentiate functional and nonfunctional requirements and explain.(r) 12. Define Data dictionary. How the data dictionary is used? Explain in detail.(may/june 2012)(April/May 2011)(U) 13. Discuss any four process models with suitable application(nov/dec 2010)(R) 14. Describe the requirement engg process and how the requirements are managed. (Nov/Dec 2012) 15. Describe the functional and behavioral models for software requirements. (Nov/Dec 2012)(U) 16. Distinguish between functional and nonfunctional requirements. State and explain nonfunctional requirements with neat sketch. (May/June 2013).(An) 17. Design a use case diagram for developing software for library mgmt system. (May/June 2013). 18. Explain viewpoints with illustrations. (May/June 2013).(U) 19. Discuss in detail about Requirement Engg Process. What are the major differences between user requirements & system requirements? (May/June 2014)(Ap) 20. What are the components of the standard structure for the software requirement document? Explain in detail. (May/June 2014)(R) 21. Write the SRS for the system of your choice. (May/June 2014)(U) 22. Write about the following requirement engineering activities. (Apr / May 2015)(U) (i) Inception (ii) Elicitation (iii) Elaboration (iv) Negotiation (v) Specification II Year / IV Sem 13

14 (vi) Validation (vii) Requirements management. 23. Draw use case and data flow diagrams for a restaurant system. The activities of the restaurant system are listed below. (Apr / May 2015)(C) 24. Explain the organization of SRS and highlight the importance of each subsection. (Apr / May 2016)(U) 25. Requirements analysis is unquestionably the most communication intensive step in the software engineering process. Why does the communication path frequency breaks down? (Apr / May 2016)(U) 26. Differentiate between user and system requirements. (Apr / May 2016)(An) 27. Describe the requirements change management process in detail. (Apr / May 2016)(Ap) COURSE OUTCOME: An Ability to compare different process models. UNIT III SOFTWARE DESIGN SYLLABUS: Design process Design Concepts-Design Model Design Heuristic Architectural Design Architectural styles, Architectural Design, Architectural Mapping using Data Flow- User Interface Design: Interface analysis, Interface Design Component level Design: Designing Class based components, traditional Components. COURSE OBJECTIVE: Able to apply systematic procedure for software design and deployment. PART-A 1. What is the use of architectural design? The Architectural design defines the relationship between major structural elements of the software, the design patterns that can be used, and the constraints that affect the way in which architectural design patterns can be applied. It also contributes Stakeholder communication System analysis Large-Scale reuse 2. Mention some of the design principles. 1. The design process should not suffer from tunnel vision. A good designer should consider alternative approaches, judging each based on the requirements of the problem. 2. The design should be traceable to the analysis model. 3. The design should not reinvent the wheel. Systems are constructed using a set of design patterns, many of which have likely been encountered before. These patterns should always be chosen as an alternative to reinvention. 4. The design should minimize the intellectual distance between the software and the problem as it exists in the real world. 5. The design should exhibit uniformity and integration. A design is integrated if care is taken in defining interfaces between design components. 6. The design should be structured to accommodate change. II Year / IV Sem 14

15 7. The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered. It should be designed to accommodate unusual circumstances, and if it must terminate processing, do so in a graceful manner. 8. The design should be assessed for quality as it is being created, not after the fact. 9. The design should be reviewed to minimize conceptual (semantic) errors. 3. Define Software Design. Software design is an iterative process through which requirements are translated into a blueprint for constructing the software. The design is represented at a high level of abstraction a level that can be directly traced to the specific system objective and more detailed data, functional, and behavioral requirements. As design iterations occur, subsequent refinement leads to design representations at much lower levels of abstraction. Design engineering encompasses the set of principles, concepts, and practices that lead to the development of a high-quality system or product. 4. Define modular design. Changes made during testing and maintenance becomes manageable and they do not affect other modules. 5. Define Fan-in and fan-out. Fan-out A measure of the number of modules that are directly controlled by another module. Fan-in Indicates how many modules directly control a given module. 6. Why it is necessary to design the system architecture before the specification are completed. (Apr/May 08) Representations of software architecture are an enabler for communication between all parties (stakeholders) interested in the development of a computer-based system. The architecture highlights early design decisions that will have a profound impact on all software engineering work that follows and, as important, on the ultimate success of the system as an operational entity. Architecture constitutes a relatively small, intellectually graspable model of how the system is structured and how its components work together. 7. Define design process. Design process is a sequence of steps carried through which the requirements are translated into a system or software model. 8. List out the principles of software design. i. The design process should not suffer from tunnel vision. ii. The design should be traceable to the analysis model. iii. The design should exhibit uniformity and integration. iv. Design is not coding. v. The design should not reinvent the wheel. 9. What is the benefit of modular design? Changes made during testing and maintenance becomes manageable and they do not affect other modules. II Year / IV Sem 15

16 10. What are the common activities in design process? i. System structuring The system is subdivided into principle subsystems components and communications between these subsystems are identified. ii. Control modeling A model of control relationships between different parts of the system is established. iii. Modular decomposition The identified subsystems are decomposed into modules. 11. What are the various elements of data design? i. Data object The data objects are identified and relationship among various data objects can be represented using ERD or data dictionaries. ii. Databases Using software design model, the data models are translated into data structures and data bases at the application level. iii. Data warehouses At the business level useful information is identified from various databases and the data warehouses are created. 12. List the guidelines of data design. i. Apply systematic analysis on data. ii. Identify data structures and related operations. iii. Establish data dictionary. iv. Use information hiding in the design of data structure. v. Apply a library of useful data structures and operations. 13. Name the commonly used architectural styles. (Nov/Dec2010) i. Data centered architecture. ii. Data flow architecture. iii. Call and return architecture. iv. Object-oriented architecture. v. Layered architecture. 14. What is real time system? Real time system is a software system in which the correct functionalities of the system are dependent upon results produced by the system and the time at which these results are produced. 15. Define Software Architecture. Software Architecture refers to overall structure of the software and the ways in which that structure provides conceptual integrity for a system. The architectural design can be represented using one or more of a number of different models. They are: i. Structural models represent architecture as an organized collection of program components. ii. Dynamic model address the behavioral aspect of the program architecture. iii. Process models focus on the design of the business or technical process that the system must accommodate. iv. Functional models can be used to represent the functional hierarchy of a system. 16. Define interface design. User-Interface design is the design of the computers, appliances, machines with the focus on the user s experience and interaction. The goal of the user-interface design is to make the user s interaction as simple and efficient as possible, in terms of accomplishing user goals. It is also called as user-centered design. II Year / IV Sem 16

17 Careful user interface design is an essential part of the overall software design process. The user interface design guidelines are: 1. User Familiarity The interface should use terms and concepts drawn from the experience of the people who will make most use of the system. 2. Consistency The interface should be consistent in that, comparable operations should be achieved in the same way. 3. Minimal Surprise Users should never be surprised by the behavior of the system. 4. Recoverability The interface should include mechanisms to allow users to recover from errors. 5. User guidance The interface should provide meaningful feedback when errors occur and provide context-sensitive user help facilities. 6. User diversity The interface should provide appropriate interaction facilities for different types of system users. 17. What is design pattern? A design pattern describes a design structure that solves a particular design problem within a specific context and amid forces that may have an impact on the manner in which the pattern is applied and used. 18. Why is architecture important? It is a representation that enables a software engineer to (1) analyze the effectiveness of the design in meeting its stated requirements, (2) consider architectural alternatives at a stage wh en making design changes is still relatively easy, and (3) reducing the risks associated with the construction of the software.(4)representations of software architecture are an enabler for communication between all parties (stakeholders) interested in the development of a computer-based system.(5)the architecture highlights early design decisions that will have a profound impact on all software engineering work that follows and, as important, on the ultimate success of the system as an operational entity.(6)architecture constitutes a relatively small, intellectually graspable model of how the system is structured and how its components work together. 19. Define archetype. An archetype is a class or pattern that represents a core abstraction that is critical to the design of architecture for the target system. In general, a relatively small set of archetypes is required to design even relatively complex systems. The target system architecture is composed of these archetypes, which represent stable elements of the architecture but may be instantiated in many different ways based on the behavior of the system. In many cases, archetypes can be derived by examining the analysis classes defined as part of the analysis model. 20. Define use case. A use-case captures the interactions that occur between producers and consumers of information and the system itself. The concept of a use-case is relatively easy to understand describe a specific usage scenario in straightforward language from the point of view of a defined actor. It describes the manner in which the actor interacts with the system. 21. What are the different techniques for user interface design? User analysis System Prototyping Interface Evaluation II Year / IV Sem 17

18 22. What is the different quality attributes? Functionality: It is assessed by evaluating the feature set and capabilities of the program, the generality of the functions that are delivered, and the security of the overall system. Usability: It is assessed by considering human factors, consistency and documentation. Reliability: It is evaluated by measuring the frequency and severity of failure, the accuracy of output results and the ability to recover from failure. Performance: It is measured by processing speed, response time, resource consumption, throughput and efficiency. Supportability: It combines the ability to extend the program, adaptability and serviceability. 23. What is functional independence? Functional independence is achieved by developing modules with singular function and the modules avoiding interaction with other modules unnecessarily. Independence is assessed by two qualitative criteria: 1. Cohesion 2. Coupling Cohesion is an indication of the relative functional strength of a module. A cohesive module performs a single task, requiring little interaction with other components in other parts of a program. Coupling is an indication of interconnection among modules in a software structure. It depends on the interface complexity between modules. High cohesion implies low coupling. 24. State Procedural abstraction. A Procedural abstraction is a named sequence of instructions that has a specific and limited function. Eg: Open Walk to the door, reach out & grasp the knob, turn knob & pull door Step away from moving door. 25. What does Data abstraction contains? A Data abstraction is a named collection of data that describes a data object Eg: door Attributes: door type, Swing direction, Opening mechanism, weight. 26. What does Modularity concept mean? (Nov/Dec 2008) Software architecture embodies modularity i.e. Software is named in to addressable components called modules, that are integrated finally. C(P1+P2) > C(P1) + C(P2) The perceived complexity of a problem that combines p1 7p2 is greater than perceived complexity when each problem is considered separately. 27. Mention some of the criteria s used to define effective modular design. Modular decomposability Modular Composability Modular Understandability Modular Continuity. Modular protection 28. Differentiate horizontal partitioning & vertical partitioning. Horizontal partitioning vertical partitioning 1. Defines separate branches of the 1.The Control & work should be Modular Hierarchy for each each distributed top-down in the program II Year / IV Sem 18

19 major program function structure. 2. Propagation of fewer side-effects 2.Higher probability of side effects. 3. Software is easier to maintain 3.susceptible to side effects when Changes are made. 29. Write down the concept of Functional independence. Functional independence is achieved by developing modules with single minded function and an aversion to excessive interaction with other modules. Independent modules, is easier to develop because function may be compartmentalized,& interfaces are simplified. Independent modules are easier to maintain. 30. What is a cohesive module? A cohesive module performs only one task in software procedure with little interaction with other modules. In other words cohesive module performs only one thing. 31. What are the different types of Cohesion? i. Coincidentally cohesive The modules in which the set of tasks are related with each other loosely then such modules are called coincidentally cohesive. ii. Logically cohesive A module that performs the tasks that are logically related with each other is called logically cohesive. iii. Temporal cohesion The module in which the tasks need to be executed in some specific time span is called temporal cohesive. iv. Procedural cohesion When processing elements of a module are related with one another and must be executed in some specific order then such module is called procedural cohesive. v. Communicational cohesion When the processing elements of a module share the data then such module is called communicational cohesive. 32. What is coupling? Coupling is the measure of interconnection among modules in a program structure. It depends on the interface complexity between modules. 33. What are the various types of coupling? i. Data coupling The data coupling is possible by parameter passing or data interaction. ii. Control coupling The modules share related control data in control coupling. iii. Common coupling The common data or a global data is shared among modules. iv. Content coupling Content coupling occurs when one module makes use of data or control information maintained in another module. 34. State Procedural abstraction. A Procedural abstraction is a named sequence of instructions that has a specific and limited function.e.g.: Open Walk to the door, reach out & grasp the knob, turn knob & pull door Step away from moving door. 35. What does Data abstraction contains? A Data abstraction is a named collection of data that describes a data object Eg: door Attributes: door type, Swing direction, Opening mechanism, weight. II Year / IV Sem 19

20 36. What does Modularity concept mean? (Nov/Dec 2009) Software architecture embodies modularity i.e., Software is named in to addressable components called modules, that are integrated finally. C(P1+P2) > C(P1) + C(P2) The perceived complexity of a problem that combines p1 7p2 is greater than perceived complexity when each problem is considered separately. 37. What is the work product of software design process and who does this? A design model that encompasses architectural, interface, component level and their representations is the primary work product that is produced during software design. Software engineers conduct each of the design tasks. 38. What are the benefits of horizontal partitioning? i. Software that is easy to test. ii. Software that is easier to maintain. iii. Propagation of fewer side effects. iv. Software that is easier to extend. 39. What is vertical partitioning? Vertical partitioning often called factoring suggests that the control and work should be distributed top-down in program structure. 40. What are the advantages of vertical partitioning? i. These are easy to maintain changes. ii. They reduce the change impact and error propagation. 41. List out design methods (May/June 2012) Functional decomposition Data Flow Design 42. Define data acquisition (May/June 2012) Data acquisition systems are commonly used in scientific experiments and process control systems where physical processes, such as a chemical reaction, happen very quickly. 43. What is meant by real time system design? (April/May 2011) A real-time system is a software system where the correct functioning of the system depends on the results produced by the system and the time at which these results are produced. It is broadly classified as: A soft real-time system is a system whose operation is degraded if results are not produced according to the specified timing requirements A hard real-time system is a system whose operation is incorrect if results are not produced according to the timing specification. 44. List four design principles of a good design (April/May 2011) The design must implement all of the explicit requirements contained in the analysis model, and it must accommodate all of the implicit requirements desired by the customer. The design must be a readable, understandable guide for those who generate code and for those who test and subsequently support the software. II Year / IV Sem 20

21 The design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective. 45. How does u apply modularization criteria for a monolithic software? (Nov/Dec 2012) In software engineering, a monolithic application describes a software application which is designed without modularity. Modularity is desirable, as it supports reuse of parts of the application logic and also facilitates maintenance by allowing repair or replacement of parts of the application without requiring wholesale replacement. Modularity is achieved to various extents by different modularization approaches. Code based modularity allows developers to reuse and repair parts of the application, but development tools are required to perform these maintenance functions (e.g. the application may need to be recompiled). Object based modularity provides the application as a collection of separate executable files which may be independently maintained and replaced without redeploying the entire application (e.g. Microsoft "dll" files, Sun/UNIX "shared object" files). 46. What are the design quality attributes FURPS meant? (May/June 2013) FURPS is an acronym representing a model for classifying software quality attributes (functional and non-functional requirements): Functionality - Capability (Size & Generalit y of Feature Set), Reusability (Compatibility, Interoperability, Portability), Security (Safety & Exploitability) Usability (UX) - Human Factors, Aesthetics, Consistency, Documentation, Responsiveness Reliability - Availability (Failure Frequency (Robustne ss/durability/resilience), Failure Extent & Time-Length (Recoverability/Survivability)), Predictability (Stability), Accuracy (Frequency/Severity of Error) Performance - Speed, Efficiency, Resource Consumption (power, ram, cache, etc), Throughput, Capacity, Scalability Supportability (Serviceability, Maintainability, Sustainability, Repair Speed) - Testability, Flexibility (Modifiability, Configurability, Adaptability, Extensibility, Modularity), Installability, Localizability 47. List the major user interface design principles. (May/June 2013) User Familiarity Consistency Minimal Surprise Recoverability User guidance User diversity 48. What are the types of Interface Design Elements? User Interfaces External Interfaces Internal Interfaces. 49. What are the basic design principles of Class-Based Components? Open-Closed Principle [OCP] Liskov Substitution Principle (LSP] Dependency Inversion Principle [DIP] II Year / IV Sem 21

22 Interface Segregation Principle [ISP] Release Reuse Equivalency Principle [RREP] Common Closure Principle ICCPI Common Reuse Principle ICRPI. 50. Draw the diagram to demonstrate the architectural styles. (APR/MAY 2015) Fig: data centered architecture Fig: Data flow architecture Fig: Layered architecture 51. List down the steps to be followed for user interface design. (APR/MAY 2015) Identification of user, task, and environmental requirements. User scenarios are created and analyze to design set of interface objects and actions. II Year / IV Sem 22