SE

B.Sc.(Computer Science): III Year SEMESTER – V

SOFTWARE ENGINEERING

UNIT - I

INTRODUCTION : The Evolving Role of Software – Software and its characteristics – Software Myths – Software Engineering – Components of Software Engineering – Software Engineering – A Layered Technology, Reactive Vs Proactive Risk Strategies – Types of Software Risks – Risk Management Process

UNIT - II

SOFTWARE PROCESS MODELS : Prescriptive Models – The Waterfall Model – Incremental Process Models: The Incremental Model, The RAD Model, Evolutionary Process Model: Prototyping Model, The Spiral Model

UNIT - III

REQUIREMENTS ENGINEERING : Requirements Engineering Tasks, Initiating the Requirement Engineering Process.

BUILDING THE ANALYSIS MODEL : Requirements Analysis, Analysis Modeling Approaches, Data Modeling Concepts, Flow – Oriented Modeling: Creating a Data Flow Model.

UNIT - IV

SOFTWARE DESIGN : Design Process & Design Quality – Design Concepts – Architectural Styles & Patterns, Quality Management: Quality Concepts – Software Quality Assurance

UNIT - V

SOFTWARE QUALITY AND TESTING : Functional testing – System Testing – User Satisfaction Testing – Test Cases – Test plans.

SOFTWARE PROJECT MANAGEMENT (SPM) – Introduction – SPM basics – Project Management – Project Integration Management – Project Life Cycle.

Text Books:

1. Roger Pressman S, “Software Engineering: A Practitioner’s Approach”, McGraw Hill, 2010.

VIKRAMA SIMHAPURI UNIVERSITY : NELLORE

CBCS – B.Sc – III YEAR – SEMESTER - V

: Software Engineering

Time: 3 Hours November-2017 Max Marks: 75 Section – A

Short Answer Questions

Answer any FIVE Questions (5 x 5M = 25 Marks) 1. Write short notes on software applications.

2. Write short notes on software risks types. 3. Explain about software engineering layers. 4. What are the drawbacks of prototyping model?

5. What is requirement engineering? What are the steps of requirement engineering? 6. Define DFD? Explain about DFDS.

7. Write short note on modularity.

8. Write short notes on quality control and quality assurance. 9. What are testing objects?

10. Discuss about software project management basics. Section – B

Answer any FIVE Questions (5 x 10M = 50 Marks)

11. Explain in detail about software characteristics and components. 12. Discuss about the risk management process.

13. Explain in detail about stages in waterfall model. 14. Explain about the phases of RAD model.

15. Describe the structure of Analysis model. 16. Discuss about data modeling concepts. 17. Discuss about cohesion and coupling. 18. Explain in detail about SQA.

19. Discuss in detail about functional testing.

20. Discuss about project estimation techniques and project scheduling 

Introduction to Software Engineering

UNIT-I

1. Software and its characteristics:

Software:

 Software is a collection of executable programming code, associated libraries and documentations.

 Software when made for a specific requirement is called software product.  Software product is developed by the computer professionals (software

engineers) to support over the long term for specific requirements. Characteristics of Software:

1. Software is developed and engineered but not manufactured:

 Software development and hardware manufacturing are almost similar, but few activities are fundamentally different.

 In both activities high quality is achieved through a good design, but

hardware manufacturing introduces more quality problems than the software 2. Software does not wear out:

 Hardware components suffer from effects of dust, vibration, temperature and many environmental problems.

 Environmental problems will not effect on the use of software.

 Environmental problems will cause the hardware to wear out and replaced by a spare part.

 Software has no spare part.

 Every software failure indicates an error in the design and process failure.  Software maintenance is more complex than hardware maintenance.

 Software is not wear out just we rectify the problem raised in the software.

3.

Component based construction:

 Software development is possible as a component based construction.  A component is a module or a part of software.

 Software components are developed independently and can be reused in many programs.

 Hardware components are not reusable components they are natural parts and they can be used only at one place

4. Portability

 Software has no physical size hence they can be moved easily from one place to another place.

 Portability of hardware is depends on physical size of the hardware. 5. Extensibility:

 Software is extensible by adding new functionalities but hardware is not extensible.

6. Functionality:

 The functionality of the software is always same in different conditions but the functionality of hardware is varying in different conditions.

2. Software Myths in the Software Engineering:

Software development myths describe a number of common beliefs or myths that software managers, customers, and developers believe falsely. This belief caused serious problems when developing software product.

a)Management Myths:

 Myth1: We already have developed software requirement specification (SRS). It is full of standards and procedures for building software.

Reality:

 The SRS standards are very well, but is it used?  Is it complete?

 Does the quality software is developed through the SRS?  Time to deliver is possible or not?

 Myth2: If we get behind the schedule, we can add more programmers. Reality:

 Software development is not a manufacturing product.

 As new people are added, the old people must spend time to educate the new people. This is time consuming process.

 Co-ordination is required between new people and old people.

 Myth3: If we decide to develop the software project with a third party. I can just relax because of third party develops the project.

Reality:

 If an organization does not understand how to manage and control software projects, it will struggle on outcome of the project.

 Myth1: Customer gives the general objectives of the software before the project development, the remaining will discuss later.

Reality:

 Exact requirements is not always possible, an unclear requirements causes disaster of software project.

 Continuous communication is required between developer and customer to develop good software.

 Myth2: Software requirements are continuously changed, but those changes can be easily accommodated because software is flexible.

Reality:

 Changing of requirements affects on development time, development cost, design modification etc.

c) Practitioner's Myths:

 Myth1: Once we write a program and it works properly, our job is done. Reality:

 Most of the projects will not work properly after they are delivered to the customers.

 The developer will also spend his effort with the customer after delivering the project.

 Myth2: There is no way to estimate the quality of the software until it will get running.

Reality:

 Actually the quality of the project is decided at the time of algorithm development.

3. Software Engineering and its Components:

Software Engineering:

 The development of software product using well defined scientific principles, methods and procedures is called software engineering.

 The outcome of software engineering is an efficient and reliable software product.

Components of software engineering:

 The activities, actions and tasks that are performed in the software engineering process are called Software Engineering components.

 The size of the component is depends on the complexity of the software.  The following are the various components of software engineering.

i. Communication ii. Planning iii. Modelling iv. Construction v. Deployment i.

Communication:- Before any technical work can begin, it is important to communicate and collaborate with the customers and stakeholders.

 The purpose of the communication is to understand the objectives of the customer and to gather the requirements of the software.

ii. Planning:

 Software development is a complicated process. So the plan is required to map the software development.

 A software plan defines

 Technical tasks to be conducted  Resources to be required

 Risks to be faced  Schedule of work iii. Modelling

 A software engineer should create different models for better understanding of requirements and design

 Different diagrams such as DFD’s, ERD’s, class diagrams, use-case diagrams are developed in the modelling.

iv. Construction:

 This activity combines code generation and testing of the software.  Testing is required to find uncovered errors in the code.

v. Deployment:

 Delivering of final software product to the customer is called Deployment. Internal components of software engineering:

 Requirement gathering: Collecting details about the product to be developed from the customer.

 Requirement specification: Creating a document containing the requirements specified by the customer.

 Software management: The way the software is planned, implemented, maintained and controlled is called software management.

 Software Scope: Determination of functionalities of software ,input requirements and how the software is to be built.

 Software estimation: Identification of size, time, effort and cost of the software.

 Risk analysis and management: Process of identifying risks, alternatives of risks.

 Software Schedule: Allocating time to each activity of the software development.

4. Software Engineering Layered Technology approach.

 Software is a collection of executable programming code, associated libraries and documentations.

 Software when made for a specific requirement is called software product.  Software product is developed by the computer professionals (software

engineers) to support over the long term for specific requirements. Software Engineering:

 The development of software product using well defined scientific principles, methods and procedures is called software engineering.

 The outcome of software engineering is an efficient and reliable software product.

Layered technology:

 Software engineering is totally a layered technology.

 It means, to develop software we go from one layer to another layer.  All the layers are related and each other.

 The following diagram shows the software engineering as a layered technology.

a) A Quality Focus:

 Quality layer is the main layer of the software engineering or development.  The main principle of any software engineering approach is to develop a

quality product.

 The "BedRock" that supports software engineering is quality focus. Here quality focuses with respect to customer, developer, end user.

Customer Quality Requirements: Efficiency and Reliability. Developer Quality Requirements: Maintainability

End User Quality Requirements: Learnability and Usability. b) Process:

 It defines a framework (structure) for software engineering that includes different activities.

 In short, it covers all activities, actions and tasks for software development.  That's why it is very important layer for software engineering.

c) Method:

 The methods are answers to all activities that are specified during the process phase.

 It is collection of all tasks such as requirement analysis, design, coding, testing and maintenance.

d) Tools:

 Software tools provide automated or semi-automated support to the process and methods.

 When tools are integrated one tool can be used by another tool. This kind of software development is called “Computer Aided Software Engineering”

5. Reactive Vs Proactive Risk Strategies

 It is common to make errors while developing projects. Such errors may occur due to human mistakes, natural disasters etc.

 The plan of minimizing such errors and rectifying its effects is known as risk management.

 There are two basic strategies that we can follow to face risks. They are

a)Reactive Risk Strategy:

The reactive risk strategy comes into action when the risks are occurred or identified. In this strategy, the risks are investigated and actions are taken to avoid similar events occurring in the future.

b)Proactive Risk Strategy:

The proactive risk strategy searches to identify all relevant risks before they are occurred.

The following are the differences between reactive and proactive risk strategies. Reactive Risk Strategy Proactive Risk Strategy Risks are identified when they are

occurred

Risks are identified in advance

Early in implementation. No implementations are involved. Active quickly and effectively when the

risks are occurred

No alternatives are defined when the risks are occurred

Minimizing damage when the risks are occur

Maximize damage when the risks are occur

No ranks are given to the risks Risks are ranked by their importance Not a good strategy for risk

management

Intelligent strategy for risk management

Lack of safety culture Good in safety culture High level training and technical people

are required to manage the risks

It is a scenario to avoid the risks

6. Types of Software Risks

Risk:

It is common to make errors while developing projects. Such errors may occur due to human mistakes, natural disasters etc. These errors are called risks. It may or may not occur.

Types of Risks:

Complex projects always face a variety of risks. One of the main duties of a project manager is to manage these risks and avoid them. While running the project, we may found different types of risks. They are

a)Software Requirement Risks:  Poor definition of requirements  Change of requirements

 Impossible requirements  Invalid requirements b)Software Cost Risks:

 Lack of good estimation  The hardware changes  Large size of project

 Extension of requirement changes  Need of automated tools

c) Software Schedule Risks:  Long term training for persons  Lack of good estimation in projects

 Change of requirements and extension of requirements  Insufficient knowledge about tools and techniques used d)Software Quality Risks:

 Insufficient documentation  Poor definition of requirements

 Lack of testing and good estimation in projects

7. Risk Management Process

Risk Management:

 It is common to make errors while developing projects. Such errors may occur due to human mistakes, natural disasters etc.

 The plan of minimizing such errors and rectifying its effects is known as risk management.

Risk Management Process :

This involves in identification, analyze, prioritize, plan, mitigate and monitoring of risks. The following are the basic activities in risk management.

a)Identify:

 Recognizing what can go wrong is the first step. It is called as risk identification.

 If we first identify all the risks properly, then we can take necessary action.

b)Analyze:

 Next, each risk is analyzed to find the possibility of its occurrence.  And also analyze the damage that it will do if it does occur.

c)Prioritize:

 Once risks are identified and analyzed, risks are ranked.  Ranking means giving priority to the risks

d)Plan:

 Finally, a plan is developed to manage those risks that have high priority to low priority.

e)Mitigate (Alternate):

 Also we search for any alternative approach to avoid the risk.  If no alternative is found, we need to face and fix the risk.

f) Monitor:

 After risks are identified, analyzed, prioritized, planned, and mitigated, we need to monitor the progress of the project.

 And if any further risks are identified, take the appropriate and corrective actions.

Software Process Models

UNIT-II

1. Prescriptive Model (or) Waterfall Model.

The model that prescribes a set of process elements such as framework activities, software engineering activities, quality assurance is called as Prescriptive Model.

Waterfall Model:

 A systematic, sequential and simplest approach to the software development is waterfall model.

 This model is also called as Linear Sequential Model or classic life cycle model.

 In waterfall model the whole process of software development is divided into different phases.

 All the phases in this model will work one after another in a linear sequential manner i.e. when the first phase is finished then only the second phase will start and so on.

 The waterfall model includes the following activities.

a)Requirement Gathering: The goal of requirement gathering activity is to collect information from the customer about the project to be developed.

b) System analysis: During the system analysis activity the software engineer (analyst) understands requirements systematically and creates requirement specification document.

c) Design: System design helps to define overall system architecture (plan) and also helps in specifying hardware and system requirements.

d)Implementation (coding): The design must be translated into machine readable form. The implementation phase performs this task. In this phase programs and modules are developed for each component of the design phase.

e)Testing: During this phase, all the programs and modules are developed in the implementation phase are tested to determine they are working properly or not. f) Deployment: Once the testing is completed, the product is spread out to the

customer environment or released into the market. This is called deployment. g)Maintenance: Maintenance is nothing but giving support to the customer after

deployment. In this activity the developer performs the following activities.  Correcting errors that were not discovered during the development phase.  Adding new functionalities.

 Porting the software to the new environment. Advantages:

 Simple and easy to understand and use.

 Phases are processed and completed one at a time.  Works well for smaller projects.

 Clearly defined stages.

 Process and results are well documented. Disadvantages:

 Not a good model for complex projects.

 It is difficult to specify all the requirements in advance.  Difficult to estimate cost and time.

 The customer must spend lot of time to receive the project.

Incremental Process Models

2. Incremental Model.

The incremental process models are the methods of software development where the product is designed, implemented and tested incrementally (a little more is added each time) until the product is finished. The product is said to be finished when it satisfies all of its requirements.

Incremental Model:

 In the incremental model, the waterfall model is applied repetitively in the linear sequence.

Requirement Gathering

Analysis Design Code Testing

Increment 1

Analysis Design Code Testing

Increment 2

Analysis Design Code Testing

Increment 3

Analysis Design Code Testing

Increment 4

 Each linear sequence produces a deliverable increment of the product.

 The first increment is called core product which contains basic requirements.  After using core product by the customer the second increment is developed

by adding additional features.

 Each subsequent release of the increment adds function to the previous release.

 This process continues until the final product is achieved.

 It is generally easier to test and debug than other methods because smaller changes are made in each increment.

 Initial product delivery is faster and costs less.

 Customer reviews are conducted after each increment which helps in developing of a good final product.

Advantages:

 Generates software product quickly and easily.  Easier to test and debug.

 Customer can respond to each iteration.

 This model is flexible to change requirements at any stage.  Easier to manage risks.

Disadvantages:

 The cost higher than the waterfall model.  Needs good planning and design.

 Requires early definition of complete system.

3. RAD Model.

The incremental process models are the methods of software development where the product is designed, implemented and tested incrementally (a little more

Business Modeling

Data Modeling

Process Modeling

Application Generation

Testing and turn over Team3

Business Modeling

Data Modeling

Process Modeling

Application Generation

Testing and turn over Team2

Business Modeling

Data Modeling

Process Modeling

Application Generation

Testing and turn over Team1

is added each time) until the product is finished. The product is said to be finished when it satisfies all of its requirements.

RAD Model:

 Rapid Application Development (RAD) is an incremental process model that includes short development cycle.

 The RAD model is a high speed model in which rapid development is achieved.

 If requirements are well understood, the development team creates fully functional with in very short time period.

 It should be used high availability of designers, developers and budget.

a)Business Modeling: In this phase all the business requirements are gathered and documented in detail.

b)Data Modeling: The information gathered in business modeling is reviewed and developed data elements.

c) Process Modeling: Process description is created by adding, removing and modifying data elements designed in the data modeling.

d)Application Generation: Reusable automated tools are developed to convert data and process model into prototypes.

Initial Requirements _Design Customer Evaluation Prototype

Review & Updating

Test Development

Maintenance

Customer satisfied Advantages:

 Reduced development time.  Quickly initial reviews. Disadvantages:

 Requires highly skilled developers and designers.  Technical risks are high.

Evolutionary Process Models

Evolutionary Process Models are iterative, that enables software engineers to develop increasingly more complete versions of the software.

4. Prototype Model:

 The prototype model is used when detailed information of the project is not available.

 This model begins with gathering of initial requirements. Developer and customer meet and discussed whatever the requirements are known.

 Then the quick design or preliminary design is created by including important aspects of a system.

 The quick design leads to the construction of prototype.

 Prototype is a working model of a project with limited functionalities.

 The developed prototype is submitted to the customer and feedback is collected.  Based on the feedback of the customer the enhanced (updated) prototype is

developed.

 This prototype developing process is continued until the required product is to be developed.

 After getting final product the developer have to test the product and give maintenance to the customer.

Planning

Risk Analysis

Engineering

Construction & Release System Evolution

Customer Communication Advantages:

 Increased user involvement in the project.  Reduces time and cost

 Defects can be detected much easier and earlier.  Quicker user feedback is available.

 Missing functionality can be identified easily. Disadvantages:

 Insufficient requirement gathering.

 Users may get confused in using of different prototypes.  Increased complexity.

 The final product may or may not match the required product.

5. Spiral Model.

Evolutionary Process Models are iterative, that enables software engineers to develop increasingly more complete versions of the software.

Spiral Model:

 The spiral model is evolutionary process model is similar to the incremental model with risk analysis.

 Spiral model is a combination of sequential and prototyping models.

 This model is best for large projects which involves continues enhancements.  All the activities are done in one iteration called spiral.

 The same activities are repeated for all spirals till the entire software is build.  The following are the various activities done in each spiral.

Requirement Engineering

Building the Analysis Model

UNIT

III

a)Customer Communication: Establishes effective communication between developer and customer.

b)Planning: Requirements are gathered during the planning phase.

c) Risk Analysis: Identifying risks and alternate solutions while developing software. d)Engineering: Developing of prototype is done during this phase

e)Construction and Release: Testing, installing and provide maintenance to the user is done during this phase.

f) Customer Evolution: Customer feedback is obtained in this phase.

Advantages:

 Risks are avoided through the risk analysis phase.  Good for large projects.

 Additional functionalities can be easily added. Disadvantages:

 Costly model to use.

 Identifying of risks is very difficult.  Does not work well for smaller projects.



End of UNIT-II

1. REQUIREMENTS ENGINEERING PROCESSES ( Or) REQUIREMENTS ENGINEERING TASKS

 The outcome of the system engineering process is depends on product specification.

 The challenge facing system engineers is “How can we develop a product that properly meets the customer’s needs and satisfies the customer’s expectations?”  There is no perfect answer to this difficult question, but a solid requirements

engineering process is the best solution.

 The requirements engineering process can be described in six distinct steps 1. Requirements elicitation

2. Requirements analysis and negotiation 3. Requirements specification

4. System modeling

5. Requirements validation 6. Requirements management Requirements elicitation:

 Requirements elicitation is the practice of collecting the requirements of a system from users, customers and other stakeholders.

 The practice is also sometimes referred to as "requirement gathering". Requirements analysis and negotiation:

 Requirements analysis is the process of determining user expectations.  The requirements must be quantifiable and detailed.

 It is common for different customers may propose conflicting requirements.

 The system engineer must settle these conflicts through a process of negotiation.  Negotiation is a compromising discussion between Customers and system

engineer.

Requirements specification:

 Requirement specification describes the function and performance of a system and the constraints that will follow in its development. .

 It serves as the foundation for software engineering.

 The Requirement Specification also describes input and output information of a system.

System modeling:

 A system model is a blue print of a system.

 System models are defined using an entity relationship diagram(ER), an object-process diagram (OPD), or a Unified Modeling Language (UML) diagram.

Requirements validation:

 Requirements validation examines to make sure that all system requirements have been stated clearly.

 Inconsistencies, omissions, and errors have been detected and corrected in requirements validation.

 The formal technical reviews are conducted to validate the requirements.

 The review team includes system engineers, customers, users, and other stakeholders.

Requirements management:

 Requirements management is the process of collecting, analyzing, refining, and prioritizing product requirements and then planning for their delivery.

 It is a continuous process throughout a project.

2. INITIATING THE REQUIREMENT ENGINEERING PROCESS:

 Requirement engineering mainly focuses on gathering the requirements.  Here customers and software engineers work together.

 They conduct some meaningful conversations to indentify the requirements.  But the entire process is not so easy and simple.

 The reasons – customers may not be available locally they may reside in different city or country or they may have no clear idea about requirements.

 There are some necessary steps to initiate requirement engineering. 1. Identifying the Stakeholders:

 Stakeholders are the people who are benefited directly or indirectly with the system to be developed.

 At beginning the requirement engineer should identify and create list of stakeholders.

2. Recognizing Multiple Viewpoints:

 There are many stakeholders related to one system. Each will have their own requirements and expectations.

 When information collected from multiple stakeholders they may be inconsistent or may conflict with one another.

 The job of requirement engineer is to sort out all stakeholder information to make proper decision.

3. Working toward Collaboration:

 Customers and other stakeholders should collaborate together with developers to develop a successful system.

 This can be accomplished by identifying the areas of commonality and conflicts.

4. Asking the First Questions:

 Communication starts between customer and developer by asking “context – free questions”, means a set of questions which help to understand the problem. Some of the questions are

 How would the output of the project characterize “good”?  What problems will face to when developing good project?  Are the customer is the right person to ask the questions?  Are the developer questions relevant to the problem?  Is the developer asking too many questions?

 Can anyone else provide additional information?

3. Software Requirements analysis

 Requirements analysis is a software engineering task that is a bridge between requirements engineering and software design.

 The result of the Requirements engineering specifies the elements such as function, data, system elements and

constraints.

 The requirements analysis provides a final requirement specification to the developer and the customer to built quality software.  Software requirements analysis may be

divided into five areas of effort: 1. Problem recognition, 2. Evaluation and synthesis, 3. Modeling,

4. Specification, 5. Review. Problem recognition:

 Initially, the analyst studies the Software Project Plan.  It is important to understand the software scope.

 The goal of recognition is understand the basic problem elements specified by the customer.

Synthesis and evaluation

 The analyst must understand flow of information, software functions, software behavior and constraints.

 The evaluation and synthesis identifies what data does the system produce, how the functions perform operations and what constrains is applied.

Modeling:

 During this phase the analyst creates models of the system.

 These models improve the understandability of data, flow, functions and behavior.

Requirement Specification:

 After modeling the analyst makes a plan and schedule for development by producing requirement specification.

 A software requirements specification (SRS) is a description of a software system to be developed.

Review:

 Review is conducted by customer and software developer to approve the requirements.

 Once the requirements are approved software design is started.

System description

Analysis Model

Design Modeling

 Analysis model operates as a link between the 'system description' and the 'design model'.

 In the analysis model, information, functions and the behavior of the system is defined and translated into the architecture in the 'design modeling'.

 The analysis model must achieve three primary objectives:  To describe what the customer requires

 To create a base for the creation of a software design, and

 To define a set of validated requirements.

 To accomplish these objectives, the analysis model uses the following structured analysis

Types of analysis models: 1. Data modeling.

 Data modeling uses Entity Relationship Diagram (ERD) to represent data objects.

 The ERD enables a software engineer to identify data objects and their relationships using a graphical notation.  The ERD defines all data that are

entered, stored, transformed, and produced within an application. 2. Scenario based Modeling:

 Elaboration of requirements is called scenario based modeling.

 This model uses use case diagram to represent the elements.

Student

Number

Class

Operations

Professor

Salary

Department

Operations

Person

Name

Phone Num

Operations

Address

Street

Village

Pin code

Operations

 Use-cases are simply an aid to defining what exists outside the system (actors) and what should be performed by the system (use-cases).

3. Class based Modeling:

 This model uses class diagrams to represent the elements of the system.

 Class diagram is a static structure diagram that describes system's classes, their attributes, operations (or methods), and the relationships among classes.

4. Behavioral Model:

 Behavioral model represent state of the system and how it is changed by the external events.

 This model uses state transition diagram (STD) to represent the elements.

 STD represents the various states of the system and the way transitions are made from state to state.

5. Flow oriented Model:

 This model uses data flow diagram (DFD) to indicate how data are transformed through the system.

 A data flow diagram is a graphical representation that depicts data flow and the data that are applied from input to output.

5. Data modeling concepts

 Analysis modeling often begins with “data modeling”.

 Software engineer defines all data objects and relationship between them in data modeling.

 Data modeling answers a set of specific questions

 What are the primary data objects in the system?  What are the attributes in each object?

 Where do the objects currently reside?  What are the relationships between objects?  Functionalities of data objects?

 Data modeling uses Entity Relationship Diagram (ERD) to represent data objects.  The ERD enables a software engineer to identify data objects and their

relationships using a graphical notation.

 The ERD defines all data that are entered, stored, transformed, and produced within an application.

 The data model consists of three interrelated pieces of information, they are 1. Data object

2. Attributes 3. Relationships Data objects:

 A data object is a representation of composite(multiple) information.

 Composite information means name of the data object and attributes of data object.

Attributes:

 Properties or characteristics of a data object are called attributes.  Attributes are used to describe the data

object Relationships:

 Data objects are connected to one another in different ways.

 A relationship is how the data is shared between Data objects.

Cardinality and Modality:

 Data objects, attributes and relationship provide the basis to understand the information domain of a problem.

 But there are some additional information related to these elements. They are “cardinality” and “modality”.

Cardinality:

 Cardinality tells how an object is related to other object.

 That is how many occurrence of an object is related to how many occurrence of other object.

 An object can be related to other in the following manner – 1. One-to-one (1:1) – An occurrence of object “A” can

relate to one and only one occurrence of object “B” and vice-versa.

2. One-to-many (1:N) – one occurrence of object “A” can relate to one or more occurrences of object “B”, but an occurrence of “B” can relate to only one occurrence of ‟A‟.

3. Many-to-many (M:N) – An occurrence of object “A” can relate to one or more occurrence of ‟B‟ and vice-versa. Modality:

 Modality tells that relation is optional or mandatory.

 If modality of a relationship is O, the relationship is optional.  If modality is 1 relationship is mandatory.

Example:

6. Flow - oriented Modeling Flow – Oriented Modeling:

 Flow models focus on the flow of data and how the data is transformed by processing functions.

 This modeling contains following elements. 1. Data flow diagrams

2. Control Specification (SPEC) 3. Process Specification (PSPEC) 1. Data flow diagrams:

 DFD is a widely used notation which shows how input is transformed into output through a system.

 Means it takes “input-process-output” view of the system.

 DFD specifies flow of information, where data comes from, where it goes and how it gets stored.

 DFD comprises of four basic notations (symbols), which help to depict information in a system.

Name Notation Description

External entry

Source or destination of data within the system.

Data Flow

Represents the movement of data from its source to destination within the system.

Data Store Indicates the place for storing_{information within the system.}

Process

Shows a transformation or manipulation of data within the system. A process is also known as bubble.

DFD rules:

 Each process should have at least one input and an output.

 Each data store should have at least one data flow in and one data flow out.  Data stored in a system must go through a process.

 All processes in a DFD go to another process or a data store. There are different levels of DFDs

Level 0 DFD

 Highest abstraction level DFD is known as Level 0 DFD, which depicts the entire information system as one diagram.

 Level 0 DFDs are also known as context level DFDs.

 There is only one process in the system and all the data flows either into or out of this process.

Customer

Web Site

Admin

Update

Confirmation Level 1 DFD –

 Level 1 DFD’s aim is to give an overview of the full system.  It depicts system in more detailed.

 Major processes are broken down into sub-processes.  Data stores may also contain in Level1 DFD.

2. Control Specification (SPEC):

 CSPES represents the behavior of the system.  It contains two things –

 State Diagram – It is a sequential specification of behavior.  Activation table – It is a combinatorial specification of behavior.

 By reviewing the state diagram a software engineer can determine the behavior.  But CSPEC doesn’t give any information about the inner working of processes. 3. Process Specification (PSPEC):

 PSPES is used to describe all flow model process through program description language (PDL).

 It can also include narrative text, mathematical equations, tables, diagrams or charts.

Design Process and Design Quality

UNIT

IV



End of UNIT-III

1. DESIGN ENGINEERING

 Design engineering starts after the requirements engineering.  The aim of software design is to develop a high-quality system.  The goal of design is to create a model of software.

 The design will implement all customer requirements correctly and provide satisfaction to the user.

 After designing the model, quality can be evaluate and improved before code is generated.

 Design concentrates on three activities – 1. Firmness – free from bugs 2. Commodity – Easy to use 3. Delight – Pleasantness in using DESIGN PROCESS AND DESIGN QUALITY

 Design is the place where software quality is established.

 Design is the only way to translate the customer’s requirements into a complete system or product.

 Without design the final system will be unstable.  There are some characteristics for good design –

 Design must implement all the implicit and explicit requirements of the customer.

 Design must be readable.

 Design must be understandable.

 Design should provide a complete picture of the software. Quality Guidelines:

 There are some guidelines for design-

 A design should show the system architecture.  A design should be modular.

 A design should implement different classes.

 A design should show independent functional components.  A design should show interfaces between components.  A design should be meaningful representation.

Quality Attributes:

 Functionality is assessed by evaluating the capabilities of the program.  Usability is assessed based on human factors.

 Reliability is evaluated by measuring the failure rate and ability to recover from the failure.

 Performance is measured by processing speed, response time and efficiency.  Supportability is the ability to extend the program.

 Adaptability and serviceability is known as maintainability.

2. DESIGN CONCEPTS

 There are a set of design concepts have been developed in the software engineering process.

 Each concept provides a foundation to develop more sophisticated design models. 1. Abstraction:

 Abstraction means hiding the details from the user.

 Many levels of abstractions are presented in the software development.  Highest level of abstraction is given in broad terms.

 The lower levels of abstraction is given in detailed description. 2. Architecture:

 Architecture means structure of the program components.

 Software architecture tells about “the overall structure of the software”.

 Software architectural design can be represented using one or more no. of different models. They are –

 Structure models  Process models  Framework models  Functional models  Dynamic models 3. Patterns:

 A design pattern describes a design structure and design type.  The aim of each design pattern is to provide a description.  Design pattern enables a designer to determine –

 Whether the pattern is applicable to current work.  Whether the pattern can be reused

 Whether the pattern can serve as a guide. 4. Modularity:

 Modularity means software is divided into small components called modules.  Then these modules need to be integrated to satisfy problem requirements.  It is easier to solve a complex problem when it is broken into pieces.

 We modularize a design for following benefits.

 Development can be more easily planned  Changes can be done more easily.

 Testing and debugging can be done more efficiently.  Long-term maintenance can be done without side-effects.

5. Information Hiding:

 Modules hide the internal information.

 The information of one module is not accessible by other modules. 6. Functional Independence:

 Each module performs independent work.

 Functional independence is a key to good design and design is the key to software quality.

7. Refinement:

 Refinement is actually a process of “elaboration”.

 Refinement elaborates the original statement by providing more and more details.

8. Refactoring:

 Refactoring is the process of changing the internal structure.

 Software is refactored when existing design is identified with - redundancy, inefficient algorithms, inappropriate data structures or any other design failure.

9. Design Classes:

 While design modeling software team must define a set of design classes.  Five different types of design classes are suggested.

 User Interface Classes  Business domain classes  Process classes

 Persistent classes

3. ARCHITECTURAL STYLES AND PATTERNS

Architectural styles: While designing the software the designer exhibits one of many architectural styles. Computer-based systems are categorized into following architectural styles

1. Data-centered architecture 2. Object-Oriented architecture 3. Data-flow architecture

4. Layered architecture

5. Call and return architecture 1. Data-centered Architecture:

 A data store is available at center of the architecture which is accessed by other client components.

 The client components operate the data store independently.

 The components can be changed and new components can be added to the architecture without concern about other clients.

2. Data-flow architecture:

 This architecture is applied when data has to pass through a

series of computation

components.

 It is identified as “pipe and filter” structure.

 Set of components is called “filters” and they are connected with “pipes”.

 Each filter works independently and doesn’t depend on its neighboring filters. 3. Call and Return Architecture:

Component Operations Component Operations Component Operations

 This architecture divides the main program into number of no of sub programs (routine).

 The main program is responsible to call the subprograms.

 After evolution of subprogram the controller return back to the main program.

4. Object Oriented Architecture:

 This architecture contains components that encapsulate data and operations.  Communication and coordination between components is accomplished via

message passing.

5. Layered Architecture:

 This architecture contains no. of different layers, each accomplishes operations.

 At outer layer components are user interface components.

 At inner layer components perform operating system interfacing.

 Intermediate layers provide utility services.

Architectural Patterns: Software architecture may have a no. of architectural patterns as follows.

1. Concurrency 2. Persistence 3. Distribution 1. Concurrency:

 This occurs when multiple parallel tasks are managed by a single processor.  There are different ways in which an application can handle concurrency –

 Operating System Management  Task Scheduler

2. Persistence:

 Data is persist if it survives after the completion of the process.

 Persistent data are stored in a database or file and may be read or modified by other processes later.

 Two architectural patterns are used to achieve Persistence  Database Management System pattern

 Application level persistence pattern. 3. Distribution:

 It tells how the components communicate with each other in a distributed environment.

 Here two things are considered.

 The way in which entities are connected together  The nature of the communication.

4. Quality Concepts Quality

 A quality is a characteristic or attribute of an item.

 A quality refers to measurable characteristics such as length, color, electrical properties, and malleability.

 The software quality characteristics include complexity, consistency, number of function points, lines of code, and many others.

Quality Control:

 Quality control involves the series of inspections, reviews, and tests used to make sure the work product meets the specified requirements.

 Quality control takes a feedback for each and every process.  The feedback useful to create a work product without fail.  Quality control activities may be automated or manual.  The feedback is essential to minimize the defects.

Quality Assurance:

 Quality assurance consists of the auditing and reporting functions of quality management.

 Quality assurance provides confidence that the product quality is meeting its goals.

Cost of Quality:

 The cost of quality includes all costs incurred to performing quality-related activities.

 Costs of quality studies are conducted to identify the current cost and how to reduce it.

 Quality costs may be divided into costs associated with prevention, appraisal, and failure.

 Prevention costs include  quality planning

 formal technical reviews  test equipment

 training

 Appraisal costs include  process inspection  equipment maintenance  testing

 Failure costs include  rework

 repair

 complaint resolution

 product return and replacement  help line support

 warranty work

5. Software Quality Assurance

 Software quality assurance (often called quality management) is an umbrella activity that is applied throughout the software process.

 It is planned to provide high degree of confidence in the quality of a product.  The Benefits of Software Quality Assurance are:

 Monitoring and Improving the Project Management Process.  Ensuring the Standards are followed or not.

 Preventing from serious problems. 

Activities of SQA:

 The Software Quality Assurance of the software is analyzed and ensured by performing a series of activities.

 A Quality Management Plan is designed and developed for the Software Quality Assurance Process.

 The plan includes number of technical methods to manage the Software Quality Assurance activities.

2. Applying Software Engineering Techniques

 The proper software engineering techniques are selected to achieve software quality.

 The techniques to be used are determined by analyzing the requirements collected.

3. Technical Reviews

 The Formal Technical Reviews [FTR] are conducted to evaluate the quality.  FTR is performed in the presence of the technical people and so will be

helpful to find the defects in the early stages. 4. Applying the Testing Strategy

 The testing strategy is designed and applied.

 The testing strategies are designed based on the policies of the company.  Testing of each phage of the system is designed and scheduled for the

concerned persons.

5. Ensuring Process Adherence

 The process adherence is the combination of 2 tasks product evaluation and process monitoring.

 Product evaluation is the process of ensuring all the requirements identified to develop a system.

 Process Monitoring is the process of observing the development of product is going in a right way or not.

6. Software Quality Assurance Audits

 Software Quality Assurance Audits inspects the Software Development Process by comparing to the established processes.

 Software Quality Assurance Auditor is the responsible person who reviews and checks the activities in the development.

 Appropriate records and reports for all the activities should be generated for future references.

 This will result in a review the performance of the Test Engineer.

SOFTWARE QUALITY AND TESTING SOFTWARE PROJECT MANAGEENT (SPM)

UNIT

V

1. Functional Testing or Black Box Testing

 Black Box Testing, also known as Behavioral Testing or functional testing.  This is a software testing method in which functionality of the software is tested

without looking at the internal code structure and implementation details.  In Black Box Testing we just focus on inputs and output of the software system  This method attempts to find the following errors:

 Incorrect or missing functions  Interface errors

 Errors in data structures or external database access  Behavior or performance errors

 Initialization and termination errors

Black Box Testing - Steps

 Initially requirements and specifications of the system are examined.  Tester identifies valid inputs and invalid inputs.

 Tester determines expected outputs for all those inputs.

 Software tester constructs test cases with the selected inputs.  The test cases are executed.

 Software tester compares the actual outputs with the expected outputs.  Defects if any are fixed and re-tested.

BLACK BOX TESTING TECHNIQUES

Following are some techniques that can be used for designing black box tests.  Equivalence partitioning:

In this technique divides the input values into valid and invalid partitions and selects values from each partition.

Testing of a login form

 Password should have between 8 and 16 characters.

 Boundary Value Analysis:

This technique determines the boundaries for input values i.e. finding the input values whether inside or outside of the boundaries.

 Error Guessing:

o This is purely based on previous experience and judgment of tester. o Error Guessing is the art of guessing where errors can be hidden. o For this technique there are no specific tools

 Comparison Testing:

Different independent versions of same software are used to compare to each other for testing in this method.

Advantages:

 Tests are done from a user’s point of view.  Tester need not know programming languages.

 Tester need not know how the software has been implemented.

 Test cases can be designed as soon as the specifications are complete. Disadvantages:

 The test inputs need a large sample space.

 Only a small number of possible inputs can be tested.

 Without clear specifications, test cases will be difficult to design.  Test engineer has required more concentration

2. System testing

 System testing is one kind of black box testing.

 This is performed to evaluate whether the system is working with all specified

requirements or not.

 This can be carried out by a special team that is independent to the development team. Types of system Testings:

Prepared by Sk.Shajahan MCA.,MTech., Page 38

Sys tem Tes ti n g S t re ss T e sti n g

III B.Sc(Semester-V) Software Engineering SV Arts & Science College – Gudur

a) Recovery testing:

 Many computer systems must recover from faults and resume processing with in s pre specified time.

 Recovery testing is a system testing which verifies the recovery is properly performed when the system is failed.

 If a recovery is automatic the re-initialization, data recovery and restart are performed to correct the failure.

 Recovery testing forces the software to fail in variety ways and recover properly in verity ways.

b) Security testing

 In a computer based system some sensitive information is hacked by hackers.  Sometimes dissatisfied employees attempt to misuse the system for revenge.  The persons who dishonest will attempt to misuse the system for personal gain.  Security testing provides protection mechanisms to protect the system from

improper use.

 During the security testing the tester plays the roles who desire to misuse the system.

c) Stress testing

 Stress tests are designed to create abnormal situations to the system.  Stress testing executes a system in a manner that demands the resources,

demand abnormal quality.  For eg

 Increasing input data rate.

 Test cases that requires maximum memory.  Test cases that requires maximum resources.  Test cases that thrashing Operating System. d) Performance testing:

 Performance testing is designed to test the runtime performance of the software.  Performance testing is performed throughout all steps in the testing process.  This test is used in

 To determine speed and stability of the sytem. Sys tem Tes ti n g

R ec o v er y T es ti n g Se c u ri ty T e sti n g

 To verify the application behavior.

 To determine how many users transactions could support.

3. Test plan

 A software test plan is a document describing the testing scope and activities.  It is the basic step performed before testing the software.

 The test plan specifies  Test items  Testing tasks

 Who will do each task?  Test environment  Test design techniques

 Test plans are classified into two types they are 1. Mater test plan

2. Phase test plan

1. Master test plan: A test plan that shows multiple test phases involved in the testing process is called Master test plan.

2. Phase test plan: A test plan that shows activities of one test phage is called Phase test plan

A typical test plan shows the following information 1. Introduction:

 Provide an overview of the test plan  Specify goals and objectives

 Specify constraints 2. References:

Phases  Unit test plan  System test plan  White box test plan  Black Box test plan

Unit test plan …………. …………. …………. ………….

System test plan …………. …………. …………. …………. Master test plan

List the related documents with links if available. 3. Test items:

List the test items and their versions. 4. Features to be tested:

Provides requirements and design specifications to be tested. 5. Features not to be tested:

 Provides requirements and design specifications not to be tested.  Specify the reasons these features would not be tested.

6. Approach:

 Mention overall approach for testing.

 Specify testing levels, testing types and testing methods. 7. Schedule:

Provide a summary of testing schedule. 8. Responsibilities:

List the responsibilities of each team or role. 9. Risks:

List the risks that have been defined. 10. Approvals:

Specify the names and roles of all persons who approve the plans. Test plan guide lines:

 Make the plan concise.  Provide complete plan

 Use lists and tables to improve the understandability.  Avoid lengthy paragraphs.

 Test plans should be reviewed many number of times for approval.  Remove unused phases.

 Update the plan when necessary.

4. Test Cases

 A test case is a document which contains set of conditions and actions to verify the software functionality.

 Test cases are documented by the quality assurance team.

 After developing the software the testing team gets ready with test cases to test the software.

 The test cases are all about “How we are going to test the software” Format of Standard test case:

Test cas e ID Descriptio n Test step s Test dat a Expecte d results Actua l result Date Of creatio n Date of executio n Create d By Execute d by

T-01 T-02

 Test case Id: The identification number of a test case.  Description: The objective or summary of a test case.  Test steps: Procedure to execute the test.

 Test data: Data required while executing the test.  Expected result: The expected output of the test.  Actual result: The actual output of the test.

 Date of creation: the date on which the test case was created.  Date of execution: The date on which the test case was executed.  Created By: Name of the person who wrote the test case.

 Executed By: Name of the person who executed the test case.

Types of test cases: 1. Formal test cases:

 Formal test cases are authorized as per the test case format.

 It has all information like input data, output data, conditions test items etc. 2. Informal test cases:

 Informal test cases are authorized orally without exact information or complete information.

Advantages:

 Test cases written in a document can be referred any time by any one.  Understands end to end functionality.

 Saves the time of the test teams.

 All requirements are tested with test cases.  Easy to understand the test process.

 Systematic approach of testing. Disadvantages:

 If any existing feature is changed the related test cases will also be changed.  Modification of test cases is very difficult and time consuming process.

Software Integrated project Management

 The way the software projects are planned, implemented , maintained and controlled is called project management.

 An effective project management focuses on the following four factors: 1. People

2. Product 3. Process 4. Project 1. People:

 The people factor is an important factor because the outcome of the software engineering is depends on the persons involved in the software development.  The model PM-CMM(Project Management-Capability Maturity Model) is

developed to fulfill the people factor.  PM-CM defines the following.

 Recruiting  Selection  Training  Performance  Work design

People involved in the project management:

 Senior manager: who define business issues is a senior manager.  Project manager: Who plan, motivate, organize and control the

developers or project manager is a project manager.

 Developer or programmer: who deliver the technical skills is a developer or programmer.

 Customer: who specify the software requirements is a customer.  End user: Who interact the released software is an end user.

2. Product:

 The project manager has no idea about the product at very beginning of the software development.

 An organized plan and estimation is required before developing the software.  Therefore we must examine the product at very beginning of the project

development. 3. Process:

 The project manager must decide which process model is appropriate for the customer requirements.

 Then the process decomposition is accomplished to divide the process into smaller components.

4. Project:

 To manage a successful software project we must understand “what can go wrong” and “How to do correct it”.

 The project manager has to take care about the following signs.  Software people do not understand the customer needs.  The product scope is poorly defined.

 Skills of the development team.  Deadlines of the project.

6. User satisfaction Testing

 User satisfaction testing is also called User Acceptance Testing (UAT).  UAT is the last phage of the testing process.

 During UAT, the actual software users test software project to make sure that the software contains all the specified requirements.



UAT performs after Unit, integration, System testing.



UAT testing is performed when all the bugs are fixed by the testing team.

Types of User Acceptance Testing There are two types of UAT testing

1. Alpha Testing:

 Alpha testing is done at developer’s environment.

 Alpha testing is performed by real users / clients and developer

 When user are using the software then developer looks they activities and if user has some Queries then developer explain them.

U s e r A c c e p t a n c e T e s ti n g U s e r A c c e p t a n c e T e s ti n g A l p h a T e s t i n g A l p h a T e s t i n g

 After the testing the user suggests some changes in the software.  Then the developer makes changes specified by the user.

2. Beta Testing:

 After the alpha testing beta testing is performed.

 Beta testing is performed at client’s environment (which is the real environment).

 Few real users test the software in real environment without any help of developer.

 Developers are not involved in the Beta testing. It is fully performed by users.  This testing is usefully to get market response of the software.

Steps involved in UAT:

 Planning: The outline of the UAT strategy is developed in this step.

 Designing test cases: Test cases are designed to test all the functionalities of software.

 Selection of testing team: The testing team is contains list end users is prepared.

 Executing test cases: The testing team executes the designated test cases.  Documenting: All bugs are entered in a testing document with relevant

comments.

 Bug fixing: The software development team makes final adjustments to the code to make the software bug free.

 Sign-off: When all bugs have been fixed, the testing team indicates acceptance of the software application.

7. Project life cycle