Software is:

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

2. 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

3. Software Characteristics Mainly Three Characteristics of Software Which Listed below: • 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 manufacturing.

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

5. Failure Curve for Software

6. 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)

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

8. 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,

9. 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.

10. 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.

11. 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.

12. 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.

13. 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

14. 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.

15. Software Process • 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)

16. 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 8) Work Product(Documents, models etc.)

17. 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.

18. 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.

19. 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.

20. 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.

21. 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.

22. 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.

23. 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.

24. 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.

25. 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.

26. 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.

27. 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.

28. 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 maintainable and testable.

29. 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.

30. 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.

31. 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.

32. 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.

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

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

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

38. 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 and easy to read programmer has to maintain it.

39. 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 and easy to modify. • Good programming is skill which can acquire by good practice only. • Some rules and guide lines can be followed by programmers.

40. There are main four type of Programming Practices: • Top Down Approach & Bottom Up Approach • Structured Programming • Information Hiding • Programming style

41. 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.

42. 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.

43. 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 performed.

44. - 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

45. 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.

46. 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).

47. Testing Fundamentals • 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. 2. Fault: Fault is conditions that cause a system fail to performing its required function. • Failure:Failure is inability of a system or component to perform require functions according to a failure is produced only when there is fault in the system .

48. 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

49. 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 program other than its specifications.

50. 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. Disadvantagesof 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.