Chapter 1

1. Chapter 1 Introduction to Software Engineering

2. Topics • Software Characteristics • Components • Applications • Layered Technologies • Processes • Methods And Tools • Generic View Of Software Engineering • Process Models- Waterfall model, Incremental, Evolutionary process models- Prototype, Spiral And Concurrent Development Model

3. Software: == Program +good user interface + operating procedures+ documentation

4. Software Characteristics • Software is a logical rather than a physical system element. Therefore, software has characteristics that are considerably different than those of hardware • Software is developed or engineered, it is not manufactured in the classical sense. • Software doesn't "wear out.“ • Although the industry is moving toward component-based assembly, most software continues to be custom built. (reusability of components)

5. Failure curve forHardware Software

6. Software crisis • Poor quality s/w produced • Development team exceeds the budget • Late delivery of s/w • User requirement not completely supported • Difficult to maintain.

7. Software Applications • System software. • Real-time software. • Business software • Engineering and scientific software • Embedded software. • Personal computer software. • Web-based software. • Artificial intelligence software.

8. Software EngineeringDefinition • [Software engineering is] the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines 2.[IEEE] The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.

9. Advantages of using S.E. • Improved requirement specification • Improved cost and scheduled estimates • Improved quality • Better use of automated tools • Less defects in final products • Better maintenance of delivered s/w • Well defined processes

10. Process, Methods, Tools / A Layered Technology

11. Quality Focus • The bedrock that supports software engineering is a quality focus.

12. Process • The foundation for software engineering is the process layer. • Process defines a framework for a set of key process areas (KPAs) that must be established for effective delivery of software engineering technology.

13. Methods • Software engineering methods provide the technical how-to's for building software. • Methods encompass a broad array of tasks that include requirements analysis, • design, program construction, testing, and support.

14. Tools • Software engineering tools provide automated or semi-automated support for the process and the methods. • When tools are integrated so that information created by one tool can be used by another, a system for the support of software development, called computer-aided software engineering, is established.

15. A Generic View of Software Engineering • The work associated with software engineering can be categorized into three generic phases, regardless of application area, project size, or complexity. • The definition phase focuses on what. • The development phase focuses on how. 3.The support phase focuses on change associated with error correction, adaptations required as the software's environment evolves, and changes due to enhancements brought about by changing customer requirements.

16. Type of change of SUPPORT PHASE • Correction: corrective maintenance changes the s/w to correct defects • Adaption: Adaptive maintenance in modification of external environment • Enhancement: Perfective Maintenance beyond to its original functions • Prevention: Preventive Maintenance, s/w reengineering- makes changes for more easiness of above 3 changes

17. Cont.. • The phases and related steps described in our generic view of software engineering are complemented by a number of umbrella activities. • Typical activities in this category include: • Software project tracking and control • Formal technical reviews • Software quality assurance • Software configuration management • Document preparation and production • Reusability management • Measurement • Risk management

18. THE SOFTWARE PROCESS

19. Cont… • A common process framework is established by defining a small number of framework activities that are applicable to all software projects, regardless of their size or complexity. • A number of task sets—each a collection of software engineering work tasks, project milestones, work products, and quality assurance points—enable the framework activities to be adapted to the characteristics of the software project and the requirements of the project team

20. Cont… • umbrella activities—such as software quality assurance, software • configuration management, and measurement2—overlay the process model. • Umbrella activities are independent of any one framework activity and occur throughout • the process.

21. Process Flow • Linear. • Iterative. • Evolutionary. • Parallel.

22. What is a Process … ? • When we provide a service or create a product we always follow a sequence of steps to accomplish a set of tasks • You do not usually • bake a cake before all the ingredients are mixed together • We can think of a series of activities as a process • The software process is the way we produce software. • Any process has the following characteristics • It prescribes all of themajor activities • It uses resources and producesintermediate and final products • It may include sub-processes andhas entry and exit criteria • The activities areorganized in a sequence • Constrains or control may apply to activities (budget control, availability of resources )

23. Software Process • For a single project • planning (time, resources, assignments) • tracking and measuring • Across multiple projects • organizational planning (time, resources, etc.) • hiring, training, tool acquisition, etc. • process assessment and improvement • For software engineering in general • helps organize the field • it is a topic of its own right (process models) 􀂃

24. Software Processes • When the process involves the building of some product we refer to the process as a life cycle • Software development process – software life cycle • A software process model is an abstract representation of a process

25. Process as a "black box" Quality? Uncertain / Incomplete requirement In the beginning

26. Problems (Black Box) • The assumption is that requirements can be fully understood prior to development • Interaction with the customer occurs only at the beginning (requirements) and end (after delivery)

27. Process as a "white box"

28. Advantages • Reduce risks by improving visibility • Allow project changes as the project progresses • based on feedback from the customer

29. Software Process Models • A process model for software engineering is chosen based on the nature of the project and application, the methods and tools to be used, and the controls and deliverables that are required. • Process model also known as software life cycle models

30. The Waterfall Model Generic Framework

31. The Waterfall Model • Requirements – defines needed information, function, behavior, performance and interfaces. • Design– data structures, software architecture, interface representations, algorithmic details. • Implementation– source code, database, user documentation, testing. • Waterfall Strengths • Easy to understand, easy to use • Each phase has well defined inputs & outputs • Each stage has well defined deliverable & Milestones. • Good for management control (plan, staff, track) • Works well when quality is more important than cost or schedule.

32. Disadvantages of Waterfall model • Once the phase x is over then next phase y started. Model is always sequential in nature. • Users have little interaction with the project team. Their feedback is not taken during development. • After the development starts changes cannot be possible easily. • Model do not support delivery of system in pieces. • Working version is available very late so review of software product from customers is also late. • Model is very rigid because output of each phases is depend on their successive stages.

33. Waterfall Model Assumptions • The requirements are knowable well in advance of implementation. • The requirements have to resolved. (related to cost, schedule, performance, safety, security, user interfaces, organizational impacts). • The nature of the requirements will not change very much • During development; during evolution • The requirements are compatible with all the key system stakeholders’ expectations • e.g., users, customer, developers, maintainers, investors • The right architecture for implementing the requirements is well understood. • There is enough calendar time to proceed sequentially and also cost of development.

34. Incremental Process Model • Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality • User requirements are prioritised and the highest priority requirements are included in early increments • Once the development of an increment is started, the requirements are frozen. • it combines elements of the waterfall model applied in iterative fashion. (iterative process model). • Example: word processing software

35. Incremental Models: Incremental C-Communication P-Planning M-Modeling C-Construction D-Deployment

36. Advantages of Incremental Model • Limited number of persons can be put on project because work is to be delivered in parts. • Customer value can be delivered with each increment so system functionality is available earlier • Early increments act as a prototype to help elicit requirements for later increments • Lower risk of overall project failure • Total cost of project is distributed. • End user’s feedback requirements for successive releases become more clear. • Testing become more easily. • Risk of failure is decrease.

37. Disadvantages of Incremental Model • Model required well defined project planning schedule to distribute the work properly. • Testing of modules result into overhead and increased cost. • Product is delivered in parts, total development cost is higher. • Well define interfaces are required to connect modules.

38. RAD Model (Rapid Application Development) • If requirements are well understood and project scope is well defined then this model is very useful. • It is high speed model to develop the project. • It is incremental model. • Important feature of RAD model is customer/user involve in all stages of development. • The process start with building rapid prototype (in 60 days) and delivered to customer for use and feedback. • Final shape of project is started after positive feedback.

39. RAD Model

40. Advantages of RAD model • Customer involved in all stages so software achieving customer satisfaction. • Feedback from the customer is available at the initial stages. • Development time of the product may be reduced due to use of powerful tools. • In order to increase productivity, case tools and framework are used. • Quick initial view of the product are possible. • Involvement of the users may increase the acceptability of the product.

41. Disadvantages of RAD model • Highly specialized and skilled developers are required. • Model is ineffective if system can not be properly modularized. • If user cannot be involved throughout the life cycle, this model is not suitable. • Absence of reusable components can lead to failure of the project. • It may be hard to use a legacy systems. Note: when to use the RAD model First, on systems that may be modularized and that are scalable Second, on systems with reasonably well known requirements

42. Evolutionary Models • This model is also known as the successive versions model. • System is first broken down into several modules or functional units that can be incrementally implemented and delivered. • The developers first develop the core modules of the system. • Next refine the modules as another incremental level by adding new functionalities. C B B A A A A,B,C are modules of a software product that are incrementally developed and delivered

43. Prototype model • Customer knows all general objectives of software but does not define input, output and functionality very clearly then this….. • In other case developer does not sure of different algorithms then… • Before developing actual software, a working prototype of the system should be built. • It is partial developed product. It has limited functional capabilities, low reliability and inefficient performance. • The prototype may be useable program but is not suitable as the final software product.

44. Evolutionary Model: Prototyping

45. Advantages of Prototype model • A partial product is built in the initial stages therefore customer get a chance to see the product early in the life cycle so give the necessary feedback. • Flexibility in design and development is also supported by the model. • Customer may be more satisfied because he is involved from starting phase. • Disadvantages of prototype model • After seeing an early prototype the users may demand the actual system to be delivered soon. • End user may not be understand the prototype model. • Poor documentation. • If user not satisfied then he may be loose the interest in the project.

46. Spiral Model • Process is represented as a spiral rather than as a sequence of activities with backtracking • Each loop in the spiral represents a phase in the process. • No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required • Risks are explicitly assessed and resolved throughout the process

47. Spiral Model

48. Simplified Spiral Model • If risks cannot be resolved, project is immediately terminated

49. Evolutionary Models: Spiral Model Identify and Resolve the risks Determine objectives And identify alternative solutions Review and plan for The next phase Develop the next Level of the product

50. Risk Assessment • Spiral Model – risk driven rather than document driven • The "risk" inherent in an activity is a measure of the uncertainty of the outcome of that activity • High-risk activities cause schedule and cost overruns • Risk is related to the amount and quality of available information. The less information, the higher the risk