1. Problem with Software Requirements are complex The client does not know the functional requirements in advance Requirements may be changing Technology enablers introduce new possibilities to deal with nonfunctional requirements Frequent changes are difficult to manage Identifying milestones and cost estimation is difficult

2. There is more than one software system New system must be backward compatible with existing system (“legacy system”) Phased development: Need to distinguish between the system under development and already released systems

3. Software Engineering The application of engineering principles and methods of design to the production of software. Use engineering principles Systematic approach

4. Aims of Software Engineering Reliable Maintainable Efficient Usable Secure

5. Software Development model The “Software Life cycle” The conception of the product to its retirement. The documented collection of policies, processes and procedures used to develop software

6. Software Development model Process in which system analysts,software engineers, programmers and end users build information systems.

7. General Principles User involved Problem solving approach Phases determined Standards for development and documentation Possibilites for revision and cancellation Design for growth and change

8. Different Models Build and Fix (what we use) 1. Write program 2. Improve it (debug, add, functionality,,improve efficiency) 3. Goto 1 Works for small 1 person projects

9. Problems with Build and fix Poor match with users needs Bad overall structure (no blueprint) Poor reliability (no systematic testing) Maintainability What happens when the programmers quits, dies, emigrates, whatever.

10. Waterfall Model Software development proceeds through an orderly sequence of successive phases. Documentation produced at end of each phase used as input to next phase. Each phase signed off. Strict no going back to previous stage Popular with managers (why?)

12. Requirement Analysis What the user wants from software What is the current system? Features Type of user (casual, experienced) Inputs and outputs

13. Functional Requirements What the program is expected to do For a set of inputs what outputs? If functional requirements not met software is faulty Example : If user tries to withdraw money from his account a check is made to ensure balance in account is greater than withdrawal amount. If balance is less than withdrawal amount the transaction is not allowed.

14. Non Functional requirements Appearances Speed Amount of memory Ease of use Example Software should have the same look and feel of a windows XP application.

15. Requirement analysis identifies Data to be processed Processes performed on the data Files used Equipment needed User views –data different user view Departments involved

16. Specification User requirements translated into technical specifications Example Chess game interface A player must be able to distinguish a vacant square from an occupied square A player must be able to determine whether it is their turn or their opponent’s If a player makes an illegal move, the player must receive feedback as to why it is illegal (square occupied)

17. Specification Data specification (data type) Test data developed Hardware specification Performance specification Training specification

18. Design How Requirements implemented System should be modular (maintenance and design) System design – partition system into modules - what should each module do? Develop algorithms for each module Data design –what data structures needed

19. Implementation Each module coded Individual modules tested Modules brought together System tested as a unit

20. Maintenance Ongoing development Reported errors fixed Upgrades

21. Waterfall Process Pros Better than “all hands to the keyboard” Work done in stages Reviews done between stages Errors caught early (cheaper to fix) Well defined process of development

22. Waterfall Process cons Too rigid, slow and cumbersome Difficult to define requirements at beginning- assumes all requirements known Once requirements agreed can’t go back (same for other stages) Documentation slows process

23. Incremental Waterfall Model Use Incremental model, each increment short duration Waterfall single release – Incremental Multiple releases At each increment better understanding Does not freeze requirements – continual feedback from customer

24. Incremental model

25. Rapid Prototyping Important Risk reduction technique Understanding increases as prototype developed Purpose – customer education - staff education Throw away prototype Evolutionary prototype (partial implementation)

26. Spiral Model Software development is Risky Do we know customers needs How much staff do we commit Have we got qualified staff Risk based approach “What are the areas of uncertainty”

28. Spiral model Spiral size corresponds to system size Distance between coils indicates resources As the system grows resources remain fixed At each succeeding spiral detail increases

29. Documentation Good documentation at all stages improves reliability and maintainability