DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING SOFTWARE ENGINEERING AND TESTING UNIT-I 1
C OURSE O UTCOMES CO1 – Perform Software engineering processes.(K2) CO2 – Make use of software design.(K3) CO3 – Apply different software testing strategies.(K3) CO4 – Illustrate different testing techniques.(K2) C O 5 – M a k e us e o f d if f e r ent l e v els o f t est i n g i n their software.(K3)
S YLLABUS UNIT I- SOFTWARE ENGINEERING PROCESSES Software engineering concepts – Development activities – Software development lifecycle models - Software project management – Project planning – Estimation – Scheduling – Risk management – Software configuration management - Project Planning – Empirical Estimation Techniques - Staffing Level Estimation – Scheduling – Organization and Team structures – Staffing - Software Requirements specification. . UNIT II- SOFTWARE DESIGN Characteristics of a Good Software Design - Coupling and Cohesion – Structured Analysis – Data Flow Diagrams - Structured and Detailed Design – Object oriented concepts - UML Diagrams - Use case model – Class diagrams – Interaction diagrams – Activity diagrams – state chart diagrams - Object Oriented Analysis and Design methodology – Characteristics of a good User Interface – Types – A User Interface Design methodology. UNIT III- SOFTWARE TESTING Introduction to Software testing – Psychology of Testing – Principles of Software Testing – Defects – Defect Prevention Strategies – Role of a tester – Software Testing Life Cycle. UNIT IV –TESTING TECHNIQUES Testing Techniques - Verification vs Validation - Software Testing Methodologies - White Box, Black Box and Grey Box - Static and Dynamic Techniques - Informal Reviews, Walkthroughs, Technical Reviews, Inspection - Structural Techniques, Black Box Techniques, Experienced Based Techniques. UNIT V – LEVELS OF TESTING Levels of Testing – Test Case Design – Building Test Cases – Test data mining – Test execution – Test reporting – Functional Testing – Unit, Integration, System, Acceptance, Regression, Retest – Non Functional Testing – Performance, Memory, Scalability, Compatibility, Security, Cookie, Session, Recovery, Ad Hoc, Risk Based Testing.
O VERVIEW 4 What is software? Components of software Types of Software Characteristics of Software Role of Software Why we need software?
5
E SSENTIAL COMPONENTS OF SOFTWARE 6 INSTRUCTIONS Functionality Performance D A T A S T R U C T U RE Essential components Maintains the data Program logic Design
C ONT .. 7 DOCUMENTATION User manual Design manual
SOFTWARE 8 Software is the general term for the various kinds of programs used to operate the computers and their related devices. That instructs the computer what to do? How to do? EXAMPLE: OPERATING SYSTEMS, WEB BROWER, GAMES
T YPES OF S OFTWARE 9 Based on Functional Domain System Software Real time software Business Software Scientific & Engineering Software Embedded Software Personal Computer Software Web based Software
S YSTEM S OFTWARE 10 Provide interface to other applications Hide ethe complexity from higher level applications
R EAL T IME SOFTWARE 11 Input data Analyze the data Take appropriate action Examples: Air traffic control system, Flood control system, network mangements System etc.,
S CIENTIFIC & ENGINEERING SOFTWARE 12 Scientific nature of the computation they perform. For ex: Ms word, Spread sheet. EMBEDDED SOFTWARE: Resides in read only memory It give product an intelligent look.
P ERSONAL COMPUTER SOFTWARE It phobic application domain It is a multi-purpose computer whose size, capabilities and price make it feasible for individual use. PCs are intended to be operated directly by an end uses, rather than by a computer expert or technician. WEB BASED SOFTWARE It is software we use over the internet with a web browser. We don’t have to install anything, download any software, or worry about upgrades. If we use online bank, web based email program like Gmail, Hotmail or yahoo mail, we are already using web- based software. 13
CHARACTERISTICS OF SOFTWARE Maintainability Correctness Reusability Reliability Portability Efficiency 14
M AINTAINABILITY 15 Allows organizations to identify improvement areas as well as determine the value supplied by current applications or during development changes. CORRECTNESS: T h e d eg r ee w i t h w hich specified requirements. so f t w a r e a d he r es t o its
R EUSABILITY 16 The ease with which software can be reused in developing other software. The use of existing assets in some form within the software product development process. Assets are products and by products of the software development life cycle and include code, software development , test suites , designs and documentations.
R ELIABILITY 17 A set of attribute that bear on capability of software to maintain its level of performance under the given condition for a stated period of time .
P O R T A B ILITY Measure 18 o f h o w e a si l y an application can be co m p u t er e n v i r o n me n t to t r a n s f er r ed f r om one another. EFFICIENCY: Ability to avoid wasting materials, energy, efforts, money, and time in doing something or in producing a desired result.
W HY WE NEED SOFTWARE ? 19 Each device needs at least one corresponding device driver, because a computer typically has at minimum at least one input device and at least one output device , a computer typically needs more than one device driver.
C HARACTERIZES OF SOFTWARE 20 Software is developed or engineered, it is not manufactured. Software does not ware out. Software is custom built.
I NTRODUCTION TO S OFTWARE ENGINEERING 21 ENGINEERING: It is a application of science, tools and methods to find cost effective solutions to problems. SOFTWARE ENGINEERING: Software engineering is the applications of principles used in the field of engineering, which usually deals with physical systems to the design , development , testing, deployment and manufactures of software systems. The field of software engineering apples the disciplined structured approach to programming that is used in engineering to software development with the stated goal of improving the quality, time and budget efficiency along with the assurance of structural testing and engineer certification.
D EVELOPMENT A CTIVITIES 22 Identification of need. Planning process. Designing. Implementation, testing and documenting. Deployment and maintenance. View model. Business process and data modelling. Computer-aided software engineering.
S OFTWARE D EVELOPMENT L IFE C YCLE M ODELS 23 Waterfall Model RAD Model Spiral Model V-Model Incremental Model Agile Model Iterative Model Big bang model Prototype Model
W ATERFALL M ODEL The waterfall is a universally accepted SDLC model. In this method, the whole process of software development is divided into various phases. The waterfall model is a continuous software development model in which development is seen as flowing steadily downwards (like a waterfall) through the steps of requirements analysis, design, implementation, testing (validation), integration, and maintenance. 24
RAD M ODEL RAD or Rapid Application Development process is an adoption of the waterfall model; it targets developing software in a short period. The RAD model is based on the concept that a better system can be developed in less time by using focus groups to gather system requirements. 25
S PIRAL M ODEL The spiral model is a risk-driven process model. This SDLC model helps the group to adopt elements of one or more process models like a waterfall, incremental, waterfall, etc. The spiral technique is a combination of rapid prototyping and concurrency in design and development activities. 26
V - M OD EL In this type of SDLC model testing and the development, the step is planned in parallel. So, there are verification phases on the side and the validation phase on the other side. V-Model joins by Coding phase. 27
I NCREMENTAL M ODEL The incremental model is not a separate model. It is necessarily a series of waterfall cycles. The requirements are divided into groups at the start of the project. 28
A GILE M ODEL Agile methodology is a practice which promotes continued interaction of development and testing during the SDLC process of any project. In the Agile method, the entire project is divided into small incremental builds. 29
I TERATIVE M ODEL It is a particular implementation of a software development life cycle that focuses on an initial, simplified implementation, which then progressively gains more complexity and a broader feature set until the final system is complete. 30
B IG BANG MODEL The Big bang model is focusing on all types of resources in software development and coding, with no or very little planning. The requirements are understood and implemented when they come. 31
P ROTOTYPE M ODEL The prototyping model starts with the requirements gathering. Th e d e v e l o p e r a n d t h e u s e r m ee t a n d de f i n e t h e p u rp o s e of t h e software, identify the needs, etc. 32
SOFTWARE PROJECT MANAGEMENT 33 A system is collection of interrelated that work together to achieve to achieve some objective. Objective: Understand software system Ability to plan a project Formulate a project development team Effectively manage the problems Produce a product according to the specifications.
C O N T .… 34 Example: Management information system of college It consists of Course Record Students Record Staff Record Result Hostel Record
P ROJECT M ANAGEMENT C ONCEPTS 35 Project: S et o f ac t i v i t i e s t o b e p er f o r me d w i t hin t i m e f r ame using defined resources. Project Management: It is the planning and controlling of the people, process and events is known as project management.
S COPE OF P ROJECT M ANAGEMENT 36 People: Organized to perform software work effective. Product: Product scope and requirements must be understood, effectively communicating with the customer. Process: The suitable process must be selected having people and product in consideration keeping in mind the complexity of work and resources.
C O N T . 37 Project: Project completion may take place within m u st b e p l a n n ed such a w a y tha t its the specified resources(time, money , equipment, people..,)
P ROJECT M ANAGER 38 To plan , motivate, organize and control the practitioners who develop the software. Ability of project Manager/Team Leader: Motivate the people Organize process in best possible manner Encourage ideas or innovations Solve problems Hold managerial identity Be achievement oriented Influence people and build team.
D EV E L O PE R S 39 Provide technical skills necessary to engineer a product. CUSTOMER: They are specify the requirements for the software to be engineered. P eo p l e can p er i p he r a l i n t e r est i n th e o u t co m e c a n also be the customers. In our example, Customer- Education experts
E ND USER 40 They are the people interact with the software once it is released for use.
S OFTWARE PROJECT PLANNING 41 Software manager is responsible for planning and scheduling project development. They manage the work to ensure that it is completed to the required standard. They monitor the progress to check that the event is on time and within budget. Scope of work to be completed Risk analysis The resources mandatory The project to be accomplished Record of being followed
42
S OFTWARE C OST E STIMATION Project scope must be established in advanced. S oft w a re metr i c s a re u s e d a s a support f r om whi c h evaluation is made. The project is broken into small PCs which are estimated individually. To achieve true cost & schedule estimate, several option arise. Delay estimation g e n e r a te Us e d s y mbol d ec omp o si tion te c hn i ques to project cost and schedule estimates. Acquire one or more automated estimation tools . 43
C OST E STIMATION M ODELS 44 A model may be static or dynamic. In a static model, a single variable is taken as a key element for calculating cost and time. In a dynamic model, all variable are interdependent, and there is no basic variable.
S TATIC , S INGLE V ARIABLE M ODELS 45 Static, Single Variable Models: When a model makes use of single variables to calculate desired values such as cost, time, efforts, etc. is said to be a single variable model. The most common equation is: C= a L b DOC=30.4L 0.90 D=4.6L 0.26 E=1.4L
S TATIC , M ULTIVARIABLE M ODELS 46 Static, Multivariable Models: These models are based on method (1), they depend on several variables describing various aspects of the software development environment. In some model, several variables are needed to describe the software development process, and selected equation combined these variables to give the estimate of time & cost. E=5.2L0.91 D=4.1L0.36
SOFTWARE PROJECT S CHEDULING To schedule the project activities, a software project manager needs to do the following: 1. Identify all the tasks needed to complete the project. 2. Break down large tasks into small activities. 3. Determine the dependency among different activities. 4. Establish the most likely estimates for the time durations necessary to complete the activities. 5. Allocate resources to activities. 6. Plan the starting and ending dates for various activities. 7. Determine the critical path. A critical path is the chain of activities that determines the duration of the project. 47
W HAT IS R ISK ? 48 Risk Management is the system of identifying addressing and eliminating these problems before they can damage the project .
C O N T … 49 Plan risk Management Identify Risk Qualitative risk analysis Quantitative Risk analysis Plan risk response Monitor and control risk
T YPES OF R ISK 50 T here are three main classifications of risks which can affect a software project: Project risks Technical risks Business risks
P RINCIPLE OF R ISK M ANAGEMENT Global Perspective : In this, we review the bigger system description, design, and implementation. We look at the chance and the impact the risk is going to have. Take a forward-looking view : Consider the threat which may appear in the future and create future plans for directing the next events. Open Communication: This is to allow the free flow of communications between the client and the team members so that they have certainty about the risks. Integrated management : In this method risk management is made an integral part of project management . Continuous process : In this phase, the risks are tracked continuously throughout the risk m a n a g e m e nt pa r adi gm. 51
R ISK M ANAGEMENT A CTIVITIES : 52
R ISK A SSESSMENT 53 The objective of risk assessment is to division the risks in the condition of their loss, causing potential. 1. Risk Identification Technology risks People risks Organizational risks Tools risks Requirement risks Estimation risks 2. Risk Analysis Avoid the risk Transfer the risk Risk reduction 3.Risk Control
S OFTWARE C ONFIGURATION M ANAGEMENT 54 When we develop software, the product (software) undergoes many changes in their maintenance phase; we need to handle these changes effectively. Several individuals (programs) works together to achieve these common goals. This individual produces several work product (SC Items) e.g., Intermediate version of modules or test data used during debugging, parts of the final product.
C ONT .. 55 Therefore, SCM is the discipline which Identify change Monitor and control change Ensure the proper implementation of change made to the item. Auditing and reporting on the change made.
S OFTWARE C ONFIGURATION M ANAGEMENT 56 When we develop software, the product (software) undergoes many changes in their maintenance phase; we need to handle these changes effectively. Several individuals (programs) works together to achieve these common goals. This individual produces several work product (SC Items) e.g., Intermediate version of modules or test data used during debugging, parts of the final product. The elements that comprise all information produced as a part of the software process are collectively called a software configuration.
SCM P ROCESS 57 It uses the tools which keep that the necessary change has been implemented adequately to the appropriate component. The SCM process defines a number of tasks: Identification of objects in the software configuration Version Control Change Control Configuration Audit Status Reporting
S OFTWARE R EQUIREMENT S PECIFICATIONS 58 The production of the requirements stage of the software development process is Software Requirements Specifications (SRS) (also called a requirements document ). This report lays a foundation for software engineering activities and is constructing when entire requirements are elicited and analyzed. SRS is a formal report, which acts as a representation of software that enables the customers to review whether it (SRS) is according to their requirements. Also, it comprises user requirements for a system as well as detailed specifications of the system requirements.
E MPIRICAL E STIMATION T ECHNIQUES 59 Empirical estimation techniques are based on the data taken from the previous project and some based on guesses and assumptions. There are many empirical estimation techniques but most popular are Expert Judgement Technique Delphi Cost Technique
S TAFFING L EVEL E STIMATION 60 Staffing level estimation Once the effort required to develop a software has been determined, it is necessary to determine the staffing requirement for the project. Putnam first studied the problem of what should be a proper staffing pattern for software projects.
P UTNAM ’ S W ORK 61 The Putnam model describes the time and effort required to finish a software project of specified size . SLIM (Software LIfecycle Management) is the name given by Putnam to the proprietary suite of tools his company QSM, Inc. has developed based on his model.
62
T EAM S TRUCTURE 63 Organization structure: Usually, each software package development organization handles many projects at any time. So f t w a r e p a c k a g e o r g a n i z a t i o n s a ss ign t ota l l y d i f f e r e n t g r oups of engineers to handle different software projects.
C O N T … 64 Project format: The project development workers are divided in support of the project that they work on (as shown below diagram). In the project format, a group of engineers is appointed to the project at the beginning of the project and that they stay with the project until the completion of the project.