Software is 1 Instructions computer programs that when

Software is: (1) Instructions (computer programs) that when executed provide desired features, function, and performance; (2) Data structures that enable the programs to adequately manipulate information and (3) Documentation that describes the operation and use of the programs

The Evolving Role of Software - Software delivers the most important product of our time-information. provides the means for acquiring information in all of its forms Transform the data so that it can be more useful in a local context Manages business information to enhance competitiveness Provides a gateway (ex. node. js) to worldwide networks like internet

Software Characteristics Mainly Three Characteristics of Software Which Listed below: 1. - - Software is developed it is not manufactured in the classical sense: Software development and hardware manufacture, these two activities are different. In both the activities, high quality is achieved through good design. Manufacturing phase for hardware can introduce quality problems that are easily corrected for software. Software costs are concentrated in engineering which means that software projects cannot be managed as if they were

2. Software doesn't "wear out. " Failure Curve for Hardware

Failure Curve for Software

When a hardware component wears out(useless), it is replaced by a spare part unlike the software spare parts. - software failure indicates an error in design which design as translated into machine executable code. - Therefore, Software maintenance involves more complexity - 3. Although the industry is moving toward component-based construction, most software continues to be custom-built (Reusability of Components)

categories of software applications System software: - A collection of programs written to service other programs are called system software. Ex. compilers, operating system, drivers

Real Time software: - Software that monitors, analyzes & controls real-world events as they occur is called real Time. - It include a data gathering component that collects and formats information from an external environment. - A output component that responds to the external environment,

Business software: Largest single software application area is Business information processing. - Discrete systems like payroll, accounts receivable or payable, inventory has develop into management information system software that accesses one or more large databases containing business information. - Applications in this area restructure existing data in a way that facilitates business operations or management decision making. -

Engineering and scientific s/w: Engineering and scientific software includes applications which is used from astronomy to volcano logy, - from stress analysis to space shuttle orbital dynamics, and - from molecular biology to automated manufacturing. -

Personal computer software. personal computer software is playing major role in the software market. - applications are word processing, spreadsheets, computer graphics, multimedia, entertainment, database management, personal and business financial applications, external network, and database access. -

Web-based software Web pages retrieved by a browser are software - It incorporates executable instructions like HTML, Perl, or Java and data may be in the form of hypertext and a variety of visual and audio formats. - Unlimited software resource that can be accessed by anyone with a modem. -

Embedded software: - Embedded software is a type of software that is build into a hardware system. - Embedded software resides in read-only memory. - It is used to control products and systems for the consumer. - Ex. Embedded software can perform functions such as keypad control for a microwave oven - Provide function and control capability like digital functions in an automobile such as fuel control, displays, and braking systems. dashboard -

Software Crisis - Projects running over-budget. Projects running over-time. Software was very inefficient(Useless). Software was of low quality. Software did not meet Customer requirements. Projects were unmanageable and code difficult to maintain. Software was never delivered Unreliable software that is expensive to maintain. Demand of new software increased faster than ability to generate new software.

Software Process is a collection of activities, actions and tasks. - Generic Process Framework include 1) Communication (Interact with Customer) 2) Planning(Create a Project Plan) 3) Modeling(Designing) 4) Construction(Coding & Testing) 5) Deployment (Deliver to Customer & Take Feedback) -

Umbrella Activities Process Framework also include Umbrella activities - It applied on s/w project - Help to manage & control progress, quality, change & risk - Umbrella Activity includes: 1) S/w Project Tracking & Control (Check Progress against Project Plan ) 2) Risk Management (affect outcome of project) 3) S/w quality Assurance 4) Technical Review(Find Error & remove it) 5) Measurement(Testing) 6) S/W Configuration Management (Change throughout S/w process) 7) Reusability Management

SOFTWARE MYTHS Management MYTH 1) We already have a book that's full of standards and procedures for building software, won't that provide my people with everything they need to know? Reality The book of standards may very well exist, but is it used? Are software practitioners aware of its existence? Does it reflect modern software engineering practice? Is it complete? Is it streamlined to improve time to delivery while still maintaining a focus on quality? In many cases, the answer to all of these questions is no.

SOFTWARE MYTHS Management MYTH 1) We already have a book that's full of standards and procedures for building software, won't that provide my people with everything they need to know? Reality The book of standards may very well exist, but is it used? Are software practitioners aware of its existence? Does it reflect modern software engineering practice? Is it complete? Is it streamlined to improve time to delivery while still maintaining a focus on quality? In many cases, the answer to all of these questions is no.

2) Myth: If we get behind schedule, we can add more programmers and catch up Software development is not a mechanistic process like manufacturing. "adding people to a late software project makes it later. “ As new people are added, people who were working must spend time educating the newcomers, thereby reducing the amount of time spent on productive development effort. People can be added but only in a planned and well co-ordinated manner.

3) Myth: If I decide to outsource the software project to a third party, I can just relax and let that firm build it. Reality: If an organization does not understand how to manage and control software projects internally, it will always in struggle when it outsources software projects.

Customer myths 1) Myth: A general statement of objectives is sufficient to begin writing programs we can fill in the details later. Reality: Detailed description of the information domain, function, behavior, performance, interfaces, design constraints, and validation criteria is necessary. These characteristics can be determined only after thorough communication between customer and developer.

2) Myth: Project requirements continually change, but change can be easily accommodated because software is flexible. Reality: It is true that software requirements change, but the impact of change varies with the time at which it is introduced.

Resources have been committed and a design framework has been established. Change that requires additional resources and major design modification, that is, additional cost. Changes in function, performance, interface, or other characteristics during implementation (code and test) have a strict impact on cost.

Practitioner's myths Myth: Once we write the program and get it to work, our job is done. Reality: Someone once said that "the sooner you begin 'writing code', the longer it'll take you to get done. " Industry data indicate that between 60 and 80 percent of all effort expended on software will be expended after it is delivered to the customer for the first Time.

Myth: Until I get the program "running" I have no way of assessing its quality. Reality: One of the most effective software quality assurance mechanisms can be applied from the beginning of a project—the formal technical review. Software reviews are a "quality filter" that have been found to be more effective than testing for finding certain classes of software defects. Myth: The only deliverable work product for a successful project is the working program. Reality: A working program is only one part of a software configuration that includes many elements. Documentation provides a foundation for successful engineering and, more important, guidance for software support.

Seven Principles of Software Development The First Principle: The Reason It All Exists A software system exists for one reason: to provide value to its users. All decisions should be made with this in mind. Before specifying a system requirement, before noting a piece of system functionality, before determining the hardware platforms or development processes, ask yourself questions such as: "Does this add real VALUE to the system? " If the answer is "no", don't do it.

The Second Principle: Keep It Simple, Stupid! - Software design is not a risky process. - All design should be as simple as possible, but no simpler. This facilitates having a more easily understood, and easily maintained system. This is not to say that features should be discarded in the name of simplicity. - Simple also does not mean "quick and dirty. “ - software must be more maintainable and less error-prone. -

The Third Principle: Maintain the Vision A clear vision is essential to the success of a software project. - Without one, a project almost unfailingly ends up being "of two [or more] minds" about itself. - As Brooks states: - Conceptual integrity(from one mind or from small team) is the most important consideration in system design. - Having a clean internal structure is essential to constructing a system that is understandable, can be extended and reorganized, and is

The Fourth Principle: What You Produce, Others Will Consume - Seldom is an industrial-strength software system constructed and used in a vacuum. - In some way or other, someone else will use, maintain, document, or otherwise depend on being able to understand your system. - So, always specify, design, and implement knowing someone else will have to understand what you are doing.

The Fifth Principle: Be Open to the Future A system with a long lifetime has more value. In today's computing environments, where specifications change on a moment's notice and hardware platforms are obsolete(outdated) when just a few months old, software lifetimes are typically measured in months instead of years. - But, true "industrial-strength" software systems must go on longer. - To do this successfully, these systems must be ready to adapt changes. - Systems that do this successfully are those that have been designed this way from the start. Never design yourself into a corner. Always ask "what if ", and prepare for all possible answers by creating systems that solve the general problem, not just the specific one. -

The Sixth Principle: Plan Ahead for Reuse - - Reuse saves time and effort. Achieving a high level of reuse is the hardest goal to accomplish in developing a software system. The reuse of code and designs has been declare as a major benefit of using object-oriented technologies. There are many techniques to realize reuse at every level of the system development process. Those at the detailed design and code level are well known and documented. How can you reuse something that you don't know exists? Planning ahead for reuse reduces the cost and increases the value of both the reusable components and the systems into which they are incorporated.

The Seventh Principle: Think! - Placing clear, complete thought before action almost always produces better results - When you think about something, you are more likely to do it right. - You also gain knowledge about how to do it right again. - If you do think about something and still do it wrong, it becomes valuable experience. - A side effect of thinking is learning to recognize when you don t know something, at which point you can research the answer. - When clear thought has gone into a system, value comes out.

A Process Framework Process framework Umbrella Activities Framework Activity #1 Action #1. 1 Work tasks Work products QA points Project Milestones Task sets. . Framework Activity #n Action #1. k Task sets Work tasks Work products QA points Project Milestones

Software Engineering - S/W community try to develop that type of technology which will make it easier, faster, and less expensive to build highquality computer programs. - The technology includes a process, a set of methods and an array of tools called as software engineering.

Definition: software engineering is : 1) Application of systematic, disciplined, quantifiable approach to the development, maintenance and operation of software.

Unit 3 Coding is programming phase to translate design of system into code in a given programming language. - To read program or to make it more readable programmer do extra work. - There are many different criteria to judge a program including readability, size of program, execution tie, and required memory for program execution. - To make it easy to understand easy to read programmer has to maintain it. -

Programming Practice Primary goal of coding is to translate given design into Source code in any programming language. - So it is easy to test, easy to understand easy to modify. - Good programming is skill which can acquire by good practice only. - Some rules and guide lines can be followed by programmers. -

There are main four type of Programming Practices: Top Down Approach & Bottom Up Approach 2) Structured Programming 3) Information Hiding 4) Programming style 1)

Top Down Approach & Bottom Up Approach - - - One question is arise at the time of coding is in what order to start building of modules from a given module hierarchy which is given at the time of Design. “To start from Top Level or Bottom Level? ” In the Top-Down implementation, implementation start from top of hierarchy and proceed to lower level. First main module is implemented then subordinates are implemented. In the Bottom-Up implementation, implementation start from Bottom of hierarchy and proceed to higher level until it reaches the top.

In which order the modules are coded that is affected in testing. - For the small system if all the modules are to be developed and then put together then at the time of testing it is not important which module is coded first. -

Information Hiding - In any problem domain only certain operations are performed on some information and only piece of information are used. Ex. A ledger account’s office has some operations regarding debit , credit, check the current balance. An operation where all debits are multiplied together and divide by sum of all credit is not

- Information is represented as data structure, only some defined operations should be performed on data structure. - Information captured in the data structures should be hidden from rest of system. - Only access functions on data structure that represent operations perform on the information should be visible. - If data structure directly used in modules them all modules that use some data structures are coupled with each other. - change is made in one of them , the effect on all other module need to be evaluated

Another form of information hiding is to let module see only those data which are needed. - Other data item should be “hidden” from such modules and other modules should not be allowed to access these data item. -

Testing - During Testing the program to be tested. - It is executed with a set of test cases. - Output of the program for the test cases is evaluated to determine if the program is performing as expected. - Testing a large system is complex activity so to divide it into smaller activities(parts).

Testing Fundamentals 1. - - Error: The term error is used in two different way: It refers the difference between a computed , observed or measured value and true, specified or correct value. Error is refers as difference between actual and ideal. Error is also used to refer human action that results in software fault.

Psychology of testing Selecting Test cases is a creative activity that is developed by tester. - Due to this reason psychology of the person is important when is doing testing activity. - The main aim of testing is to demonstrate that a program works by showing that it has no error. - The purpose of testing is to detect error that may be present in the program -

Functional Testing - - In Functional Testing structure of program is not consider. Test cases are decided on the basis of requirement of program or module. Functional testing is also called “Black box Testing” Black box test on s/w design the tester only know inputs and what the expected outcome should be. But don’t know how the program arrives at those outputs. Tester does not examine programming code and does not need further knowledge of

Advantages of Black box testing Test is unbiased(Balanced) because designer and tester are independent of each other. - Tester does not need knowledge of any specific programming Language - Test is done from the user point of view not the designer. - Disadvantages of Black box testing Test can be redundant if the s/w designer has already run test case. - Test case are difficult to design. - Testing every possible input stream is unrealistic. -

Main approaches to design Black-Box test. Equivalence Class Partitioning 2) Boundary Value Analysis 1) - In Boundary Value Analysis we choose input for a test case from equivalence class. Ex. Programmer may improperly use < instead of <= or use<= instead of <. 3) Cause Effect Graphing: - In boundary value analysis and class partitioning each input separately considered. Cause Effect Graphing is technique which select combinations of input conditions in systematic way. Ex. Input condition can be “File is empty” Which can be set true by having empty input and false by non empty file.

Structural Testing (White Box Testing) In structural testing test cases are generated on the actual code of the program and module to be tested. - This testing is also known as white box testing. - Structural testing is concerned with testing implementation of program. - Goal of this testing is not to exercise all different input and output conditions but to exercise different programming structure and data structures used in the program. -

Advantages of White box testing Knowledge of internal coding structure is required so it is easy to find which type of input data can help in testing the application. - It helps to remove extra line of code - Disadvantages of White box testing As knowledge of code and internal structure is required a skilled tester is needed to carry out this type of testing which increase cost. - It is impossible to look into every bit of code to find out hidden errors which will create failure. -

� � � � � White box testing: White box testing is done by the Developers. This requires knowledge of the internal coding of the software. White box testing is concerned with testing the implementation of the program. The intent of this testing is not to exercise all the different input or output conditions, but to exercise different programming structures and data structures used in the program. It is commonly called structural testing. White box testing mainly applicable to lower levels of testing: Unit testing and Integration Testing. Implementation knowledge is required for white box testing. Black box testing: Black box testing is done by the professional testing team. This does not require knowledge of internal coding of the application. Testing the application against the functionality of the application without the knowledge of internal coding of the software. In Black box testing the structure of the program is not considered. Test cases are decided solely on the basis of the requirements or specification of the program or module. Black box testing mainly applicable to higher levels of testing: Acceptance Testing and System Testing. Implementation knowledge is not required for black box testing.

Alpha, Beta and Gamma Testing Alpha Testing: � Alpha Testing is like performing usability testing, which is normally done by the in-house developers. � On rare occasions Alpha Testing is done by the client or an outsider. � Once the alpha testing version is released, it’s then called the Alpha Release. � Generally we perform all testing types in alpha testing phase. � Alpha testing phase ends with a feature freeze, indicating that no more features will be added to the software. � Types of testing done by tester in Alpha phase includes Smoke testing, Integration Testing, System testing, UI and Usability testing, Functional Testing, Security Testing, Performance Testing, Regression testing, Sanity Testing and Acceptance Testing.

Beta Testing: � Beta Testing is done by the number of the end users before delivery, the change request would be fixed if user gives the feedback or report defects. � The Version Release after beta testing is called beta Release. � Beta testing can be considered “pre-release testing”. � The main objective behind the Beta testing is to get the feedback from the different groups of customers and check the compatibility of the product in different kind of networks and hardware.

Gamma Testing: Gamma Testing is done when software is ready for release with specified requirements, this testing done directly by skipping all the in-house testing activities. - The software is almost ready for final release. No feature development or enhancement of the software is undertaken. - Gamma testing is the third level of testing, generally for safety. - Gamma check is performed when the application is ready for release to the specified requirements and this check is performed directly without going through all the testing activities at home. -

Test Cases - You develop test cases to define things that you must validate to ensure that the system is working correctly and is built with a high level of quality.

Test Scripts A test script is a manual or automated script that contains the instructions for implementing a test case. - You can write manual test scripts to be run by a human tester, or you can automate some or all of the instructions in the test script. - You can also associate automated functional test scripts, performance test scripts, and security test scripts with a test case. -

Test Suite The most common term for a collection of test cases is a test suite. - The test suite often also contains more detailed instructions or goals for each collection of test cases. - It definitely contains a section where the tester identifies the system configuration used during testing. - A group of test cases may also contain required steps, and descriptions of the tests. -

Test Scenario is ‘What to be tested’ and Test Case is ‘How to be tested’. - A Test Scenarios have one to many relation with Test case, Means A scenario have multiple test case. - Every time we have write test cases for test scenario. - So while starting testing first prepare test scenarios then create different-2 test cases for each scenario. - Test Scenario represents a series of actions that are associated together. Ex. - Checking the functionality of Login button is Test scenario - Test Cases for this Test Scenario are: 1. Click the button without entering user name and password. 2. Click the button only entering User name. 3. Click the button while entering wrong user name and wrong password.

Test Cases and Criteria Test Case: - cases such that successful execution of all of them implies that are to no error in the program. -

Unit 4 Software Reliability - Reliability is an important concern for most of user. - User not only want highly reliable product but also want quantitative estimation of reliability of product. - It is very difficult to measure reliability of product because there no any metrics using which we can quantify reliability of a product. - Reliability mean dependability or probability of product working correctly over a given period of time. - Reliability of product can be improve if number of defects in it is reduced. - Improvement in the overall reliability of program is depend on whether single error of program belong to core part of program or non-core part of program. - Reliability also depend on location of error in the program. - It also depend on how the product is used. - So reliability of product is dependent and can not determine correctly.

Reliability Metrics There are main six reliability metrics are used to quantify the reliability of software products. They are as under: 1) Rate of occurrence of Failure(ROCOF): - - Measures the frequency of unexpected behaviors ex. Failure A ROCOF of 2/100 means that two failures are occur in each 100 operational time units. This metrics is also known as failure intensity. This metric should be used where regular demand are made on system services and also to measure whether services are delivered correctly Ex. Bank Teller System. 2)Mean Time of Failure(MTTF) - Average Time between observed system Failures. An MTTF of 500 means that one failure can be expected every 500 time units. This metric is used where long transactions are placed. Ex. Where people use system for a log time.

3) Availability: - The probability that the system is available for use at a given time. Availability 0. 0998 means that in every 1000 time units, the system is to be available for 998 of these. This metric should be used in non-stop system where users expected the system to deliver a continuous service. Ex. Railway signaling system. - 4) Mean Time to Repair(MTTR): - Once failure occurs, some time is required to fix the error. MTTR measures the average time it takes to track the errors causing the failure and then to fix them. 5) Probability of Failure on Demand(POFOD) - - This metric is most appropriate for systems where services are demanded after long time intervals and where there are serious consequences if the service is not delivered. A POFOD of 0. 001 means one out of thousand service request may result in failure. Ex. Emergency shutdown system in a power plant.

6) Mean Time between Failure(MTBF) MTBF=MTTF+MTTR. MTBF of 300 hours indicate that once failure occurs the next failure is expected to occur only after 300 hours. In this case, the time measurements are real time and not the execution time in MTTF. - - In order to study the reliability of software product, it is necessary to classify failures into their types. A possible classification of failure is as under: 1) Transient: Transient failures occur only for certain input values while invoking a function of the system. 2) Permanent: Permanent failures occur for all input values while invoking a function of the system. 3) Recoverable: When recoverable failures occurs the system recovers with or without operator intervention. 4) Unrecoverable: In unrecoverable failure the system may need to be restarted. 5) Cosmetic: This failure can occur cause of minor irritants, but do not lead to incorrect results. Ex. May be mouse button has to be clicked twice instead of once to invoke a given function through graphical interface.

Reliability Growth Modeling - A reliability growth model is a mathematical model of how s/w reliability grows as errors are detected and repaired. A reliability growth model can be used to predict when a particular level of reliability is likely to be attained. - Following two Reliability Growth Models are mostly used 1) Step Function Model(Helsinki and Miranda Model) - The simplest reliability growth model is a step function model where it is assumed that reliability increases by constant increment each time one error is detected and repaired. - This model assumes that s/w repairs are always correctly implemented so that number of s/w faults and associated failures decreases with time. - As repair made s/w failure should decrease. -

2) Little wood and Verrall’s Model - In this model it is realized that reliability does not increase by constant amount each time an error is repaired. Improvement in reliability due to fixing of an error. Therefore growth of reliability is not constant in each time increment. They took a random element into the reliability growth improvement effected by a s/w repair. So each repair does not result in an equal amount of reliability improvement. Little wood and verrall’s Model allow for negative reliability growth when a s/w repair introduces further errors.

Objective of S/W Quality Management 1. 2. 3. 4. 5. To introduce the quality management process and activity. To explain the role of standards in quality management. To explain concept of s/w metric, analyst metric and control metric. To explain how measurement may be used in assessing s/w quality and the limitations of s/w measurement. S/W product fitness purpose is in term of satisfaction of requirements laid down in the SRS document. There are some of quality factors are described as under: Portability Usability Reusability Correctness Maintainability

S/w Measurement and Metrics