Possible Solutions

BN-209 Software Engineering

Mahesh Vaghamshi MIT09298 2/17/2011

Definitions: Software Engineering: The application of a systematic disciplined, quantifiable approach to the development, operation and maintenance of software; that is the application of engineering to software. Software Process: A process defines who is doing what, when and how to reach a certain goal. A process is a collection of activities, actions, and tasks that are performed when some work product is to be created. Supply Chain Management: incorporates processes that seamlessly integrate product development, product acquisition, manufacturing, and inventory management. MVC: is a classic design pattern often used by applications that need the ability to maintain multiple views of the same data. Models for maintaining data, views for displaying all or a portion of the data, and controllers for handling events that affect the model or view(s). Cohesion: A cohesive module performs a single task, requiring little interaction with other components in other parts of a program. Stated simply, a cohesive module should (ideally) do just one thing. Coupling depends on the interface complexity between modules, the point at which entry or reference is made to a module, and what data pass across the interface. Agility: Effective (rapid and adaptive) response to change, Effective communication among all stakeholders, Drawing the customer onto the team, Organizing a team so that it is in control of the work performed Process Pattern: describes a process-related problem that is commonly encountered in software engineering, it identifies the environment in which the problem has been encountered, and suggests one or more proven solutions. Scrum: A quick, adaptive, and self-organizing development methodology which responds to a current situation as rapidly and positively as possible. Model Driven Architecture: OMG (Object Management Group) initiative, built on the principles of abstraction, modelling, reuse, and patterns. It provides companies with a framework to identify and classify all system development work being done in an enterprise ISO 9001:2000 for software: a generic standard that applies to any organization that wants to improve the overall quality of the products, systems, or services that it provides.

Models and Modelling: Complex systems require more than one type of model Models represent some aspect of the system being built. Process of creating models helps analyst clarify and refine design which is modelling. Stub: A piece of code that simulates the activity of missing components. For EX : If we have Modules x,y,z . X module is ready and Need to Test it , But it calls functions from y and z.(Which is not ready)To test at a particular module we write a Small Dummy piece a code which Simulates Y and Z Whch will return values for X, These pice of Dummy code is Called Stubs in a Top Down Integration So Stubs are called Functions in Top Down Integration. Driver : A piece of code that passes test cases to another piece of code. Similar to the above ex: If we have Y and Z modules get ready and x module is not ready, and we need to test y and z modules Which return values from X,So to get the values from X We write a Small Pice of Dummy code for x which returns values for Y and Z,So these piece of code is called Drivers in Botton Up Integration Domain Analysis: is the process of analysing related software systems in a domain to find their common and variable parts. Aggregation: whole-part relationships between and object and its removable parts Composition: whole-part relationships between and object and its nonremovable parts. Adaptor Pattern:

PART A: Descriptive questions (60 - 70%). A1: A System Analyst requires Technical Knowledge; Business Knowledge; and People Knowledge. Explain this statement in your own words. Provide an example of each type of knowledge and explain how it relates to System Analysis. A system analyst requires a technical knowledge in terms of he has at least fundamental technology knowledge of computers/hardware, files and database system, Input and output components and alternatives, computer networking protocols, programming languages, operating systems etc.

For example, Analyst must know how to operate the OS like windows and Linux and he should be able to at least understand the basic code of the program which is written in C language. Moreover, he must require the business knowledge; analyst must have to understand business functions performed by the organization, strategies, plans, traditions, and values of organization, organization structure. For Example, Analyst are studying this kind of business units in their relevant courses like BIS or MIS. Furthermore, Analyst requires people knowledge. First of all he must be an effective communicator. A system analyst must be able to perform various roles such as negotiator, teacher, mentor etc. For Example: To convince the client on his analysis on the problem, he must need effective communication and negotiation skills A2: A Process framework for Software Engineering includes five things: work tasks; work products; milestones and deliverables; QA checkpoints; and umbrella activities. Explain each of the five items. Provide an example of each item and explain how it relates to Software Engineering. Work Task: A specified amount of work, set of responsibilities, or occupation assigned to an individual or to a group. For example: A task of designing the prototype of web page. Work Product: It is a deliverable or outcome (such as a training course or a building) that must be produced to complete a project and achieve its objectives. Milestone: Within the framework of project management, a milestone is the end of a stage that marks the completion of a work package or phase, typically marked by a high level event such as completion, endorsement or signing of a deliverable, document or a high level review meeting. For example: Testing Phase during the project life cycle can be classified as a milestone. Deliverables:

A project management term for the quantifiable goods or services that will be provided upon the completion of a project. Deliverables can be tangible or intangible parts of the development process, and are often specified functions or characteristics of the project. For Example: final work products. QA checkpoints: They are responsible for performing internal quality assurance reviews at agreed checkpoints throughout planning projects. It is standard assessment. For Example: QA for the software coding. Umbrella Activities: The above mentioned all activities can be classified as a umbrella activities in software engineering. For example : SDLC phases does have a name, same like that this all activities called as umbrella activities in software engineering. A3: There are two main approaches to the System Development Lifecycle: predictive and adaptive. Explain both approaches. What are the advantages of each approach ? What are the disadvantages of each approach ? When should a predictive approach be used ? When should an adaptive approach be used ? Predictive approaches: assumes project can be planned out in advance. This approach use while, project requirements well understood and well defined and Low technical risk in the project Advantages: Project planning initiate, ensure feasibility, plan schedule, obtain approval for project Analysis understand business needs and processing requirements Design define solution system based on requirements and analysis decisions Implementation construct, test, train users, and install new system Support keep system running and improve

Disadvantages: Example: myki Adaptive approaches: More flexible, assumes project cannot be planned out in advance. This approach use while, project requirements and needs uncertain and high technical risk.

Advantages: o Project cycles through development activities over and over until project is complete o Prototype created by end of each cycle o Focuses on mitigating risk

Disadvantages: Example: Yarra Employee Self Service System A4: There are several variations of the System Development Lifecycle. Explain each of the following variations. Provide a diagram as part of your explanation. In the diagram show the major phases of the lifecycle and how they are related. Explain the benefits and disadvantages of each variation. Waterfall
Communication
project initiation requirement gathering

Planning
estimating scheduling tracking

Modeling
analysis design

Construction
code test

Deployment
delivery support f eedback

The Waterfall model is a sequential development approach, in which development is seen as flowing steadily downwards (like a waterfall) through the phases of requirements analysis, design, implementation, testing (validation), integration, and maintenance. Incremental Adaptive Approach

A series of mini-Waterfalls are performed, where all phases of the Waterfall development approach are completed for a small part of the systems, before proceeding to the next incremental, or Advantages:

More flexible - less costly to change scope and requirements. Easier to test and debug during a smaller iteration. Easier to manage risk because risky pieces are identified and handled during its iteration Disadvantages:

Each phase of an iteration is rigid and do not overlap each other. Problems may arise pertaining to system architecture because not all requirements are gathered up front for the entire software life cycle. Prototyping

In this model, a prototype (an early approximation of a final system or product) is built, tested, and then reworked as necessary until an acceptable prototype is finally achieved from which the complete system or product can now be developed. Spiral - Adaptive Approach

This model of development combines the features of the prototyping model and the waterfall model. The spiral model is favoured for large, expensive, and complicated projects.

A5: What is a scenario? What is a scenario used for in software engineering? Write a scenario for using an ATM (Automated Teller Machine). Now that you have written the scenario, what would it be used for by a system analyst/software engineer? Scenario: Scenario can be defined as a use case scenario, it can be defined as a user story. It can be defined as a particular functionality of system but which defines pre conditions post conditions, pre requirements and the post requirements and also what are the exclusions of the functionality. Scenario is a story about the functionality. It also defines how we finish up with that particular functionality. For example: Accept payment from customer can be scenario. ATM Put the card in than select which account To withdraw a payment money has to check different condition in terms of limits Withdrawing amount is over the limit that also not let the customer not to withdraw amount. Let the customer withdraw the money Pre condition - User of ATM must have valid ATM card to access the ATM machine. Exclusion - during the transaction he wants to cancel the transaction. Post condition - withdraw antother transaction. Post condition - receipt or not?

MIT MIT Online Enrolment Scenario - To enrol into particular subjects Trigger - Enrolment Precondition - Student must be login with MIT authenticated UserID and Password as well as Student must paid the fees Post conditions - Student can create a time table only after the enrolment Assumptions - NA Student clicks on enrolment tab on MIT online Enrolment System Selects the subjects click on enrol button. Exclusion - Student can only be enrol in more than 4 subjects if administrator approves his application. Pizza Ordering Pizza Online Ordering System Scenario - To order online pizza Trigger - Ordering Precondition - Customer must be registered user. Post condition Customer can paid online or on delivery Assumptions - NA Customer clicks on OrderNow tab on Pizza Ordering online System Selects the size of pizza Selects the type of pizza Selects the topping for pizza Clicks on Submit button to process the pizza order. Exclusion Customer can add the drinks as well with the order.

A6: Requirements need to have the following characteristics: verifiable; complete; non-ambiguous; modifiable; and traceable. Explain each of these characteristics in your own words, and provide an example of each characteristic. Unambiguous Every requirement has only one interpretation. Each characteristic of the final product is described using a single unique term. A glossary should be used when a term used in a particular context could have multiple meanings. Complete A complete requirement have following qualities: Verifiable Every requirement must be verifiable. There must exist some finite cost-effective process with which a person or machine can check that the software meets the requirement. contains all the information that is needed to define a system function. Leaves no one guessing, and Includes measurement units.

Modifiable The requirements should be structured so that it is possible to change it at little to no cost. Traceable The requirements should be structured so that it is possible to uniquely identify each requirement. Each one should have a unique number (e.g. 10.0.0.1). This allows it to be referred to in final testing of the delivered software and in discussions with a client. A7: There are four elements of requirements analysis: scenario based models (use case diagrams) ; class based models(class diagrams); behaviour based models (sequence diagrams) and flow models (data flow diagrams). Explain each of the four elements, and provide an example of each. 1). Scenario Based models: Scenarios based models are expected or anticipated system uses from both user and developer views and they provide a look at how the system satisfies quality attributes in various use contexts. A use can diagram can be used as a scenario based model.

2). Class Based Models: It shows External entities that produce or consume information and roles played by people who interact with the system. It also depicts structures that define a class of objects.
Computer Building buildingNumber buidingName
1 1..*

Lab labNumber roomNumber operatingHours numberAttendants

1 1..*

computerID seatLocation make processorSpeed memoryAmount monitorType

3). Behaviour Based Models: Similar to Scenario based models, behaviour based models depicts how the systems use cases and actors are interacts with each other.

4). Flow Model: Flow model can be described a data flow diagram. It shows the flow of data in the system. It includes various entities, data stores etc.

A8: Draw an entity relationship diagram, including minimum and maximum cardinality, for the following: The system stores information about two things: cars and owners. A car has attributes for make, model, and year. The owner has attributes for name and address. Assume that a car must be owned by one owner, and an owner can own many cars, but an owner might not own any cars (perhaps she just sold them all, but we still want a record of her in the system).

Owner Ow_Name Ow_Add

Car Car_make Car_model Car_year

A9: There are three golden rules of user interface design: 1) place the user in control, 2) reduce the users memory load, and 3) make the interface consistent. Explain each of these in your own words, and provide an example of each rule. 1) Place the user in control Define interaction modes in a way that does not force a user into unnecessary or undesired actions. The user should always be able to enter and exit the mode with little or no effort.

Provide for flexible interaction. Because different users have different interaction preferences, choices should be provided by using keyboard commands, mouse movements, digitizer pen or voice recognition commands 2) Reduce the users memory load Reduce demand on short-term memory. Provide visual cues that enable a user to recognize past actions, rather than having to recall them. Establish meaningful defaults. A user should be able to specify individual preferences; however, a reset option should be available to enable the redefinition of original default values. 3) Make the interface consistent. Allow the user to put the current task into a meaningful context. The user should be able to determine where he has come from and what alternatives exist for a transition to a new task. Maintain consistency across a family of applications. MS Office Suite If past interactive models have created user expectations, do not make changes unless there is a compelling reason to do so. Once a particular interactive sequence has become a de facto standard (Ctrl-S save file), the user expects this in every application they encounters. A10: In software design, what is cohesion ? Why does a quality software design have high cohesion ? Provide an example of high cohesion in a design. In software design, what is coupling ? Why does a quality software design have low coupling ? Provide an example of low coupling in a design.

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. Stated simply, a cohesive module should (ideally) do just one thing. Coupling is an indication of the relative interdependence among modules. Coupling depends on the interface complexity between modules, the point at which entry or reference is made to a module, and what data pass across the interface.

A11: There are many different ways to measure the quality of software. Identify and explain five different ways to measure the quality of software. Provide an example of each. Performance Quality. Does the software deliver all content, functions, and features that are specified as part of the requirements model in a way that provides value to the end-user? Feature quality. Does the software provide features that surprise and delight first-time end-users? Reliability. Does the software deliver all features and capability without failure? Is it available when it is needed? Does it deliver functionality that is error free? Durability. Can the software be maintained (changed) or corrected (debugged) without the inadvertent generation of unintended side effects? Will changes cause the error rate or reliability to degrade with time? Serviceability. Can the software be maintained (changed) or corrected (debugged) in an acceptably short time period. Can support staff acquire all information they need to make changes or correct defects? A12. What is software quality assurance? software quality assurance. Describe the basic steps in

SQA means of monitoring the software engineering processes and methods used to ensure quality. Define customer requirements and deliverables and project goals via welldefined methods of customer communication Measure the existing process and its output to determine current quality performance (collect defect metrics)

Analyze defect metrics and determine the vital few causes. Improve the process by eliminating the root causes of defects. Control the process to ensure that future work does not reintroduce the causes of defects. A13: What is white box testing ? What is black box testing ? When should white box testing be used ? When should black box testing be used ? What is a good test ? White-box testing is a method of testing software that tests internal structures or workings of an application. In white-box testing an internal perspective of the system, as well as programming skills, are required and used to design test cases. Programmer will test the code by himself. He knows about the code and how to test. To test individual functionality of the system. Black-box testing It is a method of testing software that tests the functionality of an application as opposed to its internal structures or workings (see white-box testing). Specific knowledge of the application's code/internal structure and programming knowledge in general is not required. In Black-box testing users sits in a black-box. He does not aware anything about the system. He does not aware of any code of the system. He just give the input to the system and he will get the output from the system. It can be done by the customer itself. Black box testing specifies the requirements. What is a good test ? Good test includes Unit Testing, Integration Testing (white box testing, black box system), System Testing.

PART B: Case Study (30 40%) Questions that may be asked about the case study: B1: Provide a context diagram and a Level 1 Data Flow Diagram for the case study. B2: Provide an entity relationship diagram for the system that stores information about Customers and Bank Accounts (Case Study 1) or Customers and Items (Case Study 2). B3: Provide a class model for the system that stores information about Customers and Bank Accounts (Case Study 1) or Customers and Items (Case Study 2). Include the different types of Bank Accounts (Items) in your class model. B4: Identify five functional requirements for the system. B5: Identify five non-functional requirements for the system. B6: All requirements should be able to be verified. your requirements from B2 and B3 can be verified. Explain how each of

The Case Study on the final exam will be one of the following: CASE STUDY 1 You are the System Analyst on a team that is going to develop software for an online banking system. Bank customers have access to all of their bank accounts through the system. This includes savings accounts, checking accounts, loans, and credit cards. All customers have at least one checking account. A customer may have more than one savings account, loan, or credit card. Bank account information is private and can not be accessed by the public or by other bank customers. Customers can access the system over the Internet. Bank customers want to complete the following activities: check balance; transfer funds between accounts; transfer funds to external accounts; and make payments. To transfer funds, the customer specifies the amount and the place where the money should go. The bank has to protect customers from fraud and from making mistakes. So limits should be placed on the amount that can be transferred. Customers also need to be able to double check their entries before funds are actually transferred. Customers also need a receipt for the transaction, and this can be sent via email. The bank needs to keep records of all transactions. Some customers use dial up Internet connections, while others use faster connections. Network and computer failures can occur while a customer is using the system. Customers may use the system in a public area, such as a public library or an Internet caf. CASE STUDY 2 You are the System Analyst on a team that is going to develop software for an online library. Customers can browse the library to find an item. Items can be books, magazines, newspapers, journals, CDs, and DVDs. Each item has an library catalog number, and every customer has an ID number. Once a customer finds an item that he/ she wants, they can request it. If the item is not available, they can reserve it. Customers have library accounts, and they are not allowed to borrow an item if they have any outstanding fines. A customer can borrow up to five items at a time. A customer selects items and puts them in a collection. The collection is finalised when the customer completes their transaction. Each customer has their own account, and they are not allowed to let other people use it. The library has to keep an accurate record of items, so they do not lose stock. A lot of money has been invested in the library.

Customers can pay fines online with their credit cards. This requires bank authorisation. Some customers use dial up Internet connections, while others use faster connections. Network and computer failures can occur while a customer is using the system. Customers may use the system in a public area. Regards Case study : 1

class Class Model

Client ID: int name: char address: char contactDetails: char

Account Checking Account accountNumber: int openedDate: date closedDate: date intrestRate: int monthlyFee: int balance: int

Credit Card Account cardNumber: int holderName: char expiryDate: date Sav ing Account Loan Account

Case Study : 2 Context Diagram :

Login Book Information

Book Borrow

AITE Library Management System

Book Search

Registration

Issue Details

Change Password

Fine Details

Data Flow Diagram:

Librarian

Librarian Entry

Student

Login System

Valid User

Student Entry

Invalid UserID or Password

ER Diagram:
+----------------+ | BOOK | |----------------| | ISBN(PK) | reserves (0,n) | bName | +-------<------------->---------| pubDate(fk) | | r_date | pubId(fk) | | | ageLower | | | ageUpper | | | value | +------------+ +----------------+ | Member | | (0,n) |------------| | | memId(PK)# | <stock> | memname | | | memaddress | | (1,1) | memMaxbooks| +--------------+ | | | COPY | +------------+ |------------ | |(0,n) borrows (0,1) | cId(PK)# | +------<------------->----------| ISBN(fk) | | dateRequired | | dateDestroyed| l_date +--------------+

Class Diagram
class Class Model

Library Customer ID: int name: char address: char Account booksReading booksReserved: int name: char address: char Accounts: char

Book ISBN: int author: char publisher: char