1. 1 Software Engineering - 66312 Chap 1 Instructor : Haya Samamneh

2. 2 What is a software process? A set of activities whose goal is the development or evolution of software Generic activities in all software processes are: –Specification - what the system should do and its development constraints –Development - production of the software system –Validation - checking that the software is what the customer wants –Evolution - changing the software in response to changing demands

3. 3 What is CASE (Computer-Aided Software Engineering) Software systems which are intended to provide automated support for software process activities. CASE systems are often used for method support Upper-CASE –Tools to support the early process activities of requirements and design Lower-CASE –Tools to support later activities such as programming, debugging and testing

4. 4 Chapter 2 Socio-technical Systems (Computer-based System Engineering)

5. 5 System Engineering Is the activity of specifying, designing, implementing, deploying, maintaining systems, which include hardware, software, people and interaction of the system with users and its environment.

6. 6 Examples of emergent properties The reliability of the system –This depends on the reliability of system components and the relationships between the components. The usability of a system –This is a complex property which depends on the system operators and the environment where it is used.

7. 7 Types of emergent properties Functional properties –These appear when all the parts of a system work together to achieve some objective.

8. 8 Types of emergent properties Non-functional emergent properties –Examples are reliability, performance, safety, and security. –These relate to the behaviour of the system in its operational environment. –They are often critical for computer-based systems as failure that may make the system unusable.

9. 9 Because of component inter-dependencies, faults can be propagated through the system, so failure in one component can affect the operation of other components. System failures often occur because of unforeseen inter-relationships between component. Complexity of emergent system properties- reliability

10. 10 –Safety - the system that reflects the system’s ability to operate without danger –Security - the system should not permit unauthorised use

11. 11 Using spiral process, each round on the spiral may add more detail to design.

12. 12 The system engineering process

13. 13 Spiral model of requirements and design Spiral process 2

14. 14 Chapter 2, Cont… Socio-technical Systems (Computer-based System Engineering)

15. 15 7- System evolution Large and complex systems have a long lifetime. They must evolve to meet changing requirements[ error in system or change environment] Evolution is inherently costly because: –Changes must be analyzed from a technical and business perspective [after changing must get the same goal of the system] –Sub-systems interact [change in subsystem may affects on other subsystems]so problems can arise –As systems Age: System structure is corrupted as changes are made to it, so the cost of making changes increases Existing systems which must be maintained are sometimes called legacy systems

16. 16 Critical Systems Chapter 3 Instructor: Haya Sammaneh

17. 17 Critical Systems It is the systems that fail to deliver the expected objective in which any system failure can result in economic losses, physical damage or human life loss.

18. 18 Dependability Principal dimensions of dependability are: –Availability; –Reliability; –Safety; –Security;

19. 19 Dimensions of dependability

20. 20 Other dependability properties Repairability –Reflects the extent to which the system can be repaired in the event of a failure Maintainability –Reflects the extent to which the system can be adapted to new requirements; Survivability –Reflects the extent to which the system can deliver services whilst under hostile attack; Error tolerance –Reflects the extent to which user input errors can be avoided and tolerated.

21. 21 Chapter 4 - Part 1 Software Processes

22. 22 The software process A set of activities required to develop a software system such as: –Specification, functionality and constraints must be defined. –Design and implementation, software meet the specification must be produced. –Validation, it does what the customer wants. –Evolution, must evolve to meet changes.

23. 23 software process model A software process model is an abstract representation of a process.

24. 24 Generic software process models The waterfall model –Separate and distinct phases of specification and development Evolutionary development –Specification and development are interleaved Reuse-based development –The system is assembled from existing components

25. 25 Waterfall model

26. 26 Waterfall model Linear sequential model Distinct stages with deliverables at the end of each phase The main advantage : Each phase is terminated with the approval of a document. high process visibility—it is easy to see where in the process you are.

27. 27 Waterfall model problems The drawback of the waterfall model is the difficulty of making changes after the process is underway Therefore, this model is only appropriate when the requirements are well-understood The waterfall model is mostly used when the project is part of a larger systems engineering projects where a system is developed at several sites.

28. 28 Evolutionary development Is based on the idea of developing an initial implementation, exposing this to user and refining it through many versions until a system has been developed.

29. 29 Evolutionary development

30. 30 Evolutionary development-types Exploratory development –Should start with well-understood requirements, and work with the customer to explore their requirements to deliver a final system. –The system evolves by adding a new feature proposed by the customer. Throw-away prototyping –Objective is to understand the customer’s requirements and develop a better requirements for the system. Should start with poorly understood requirements

31. 31 Chapter 4 Part-2 Software Processes

32. 32 In Ch4 Lec 5 – Part 1 we discuss: 1- Generic software process model a. waterfall model b. evolutionary model c. Formal systems d. reuse- based component model In Ch4 Lec 5 – Part 2 we discuss: 2- Iterative process model a. Incremental development (delivery) b. Spiral development 3- software process 4- CASE tools

33. 33 Process iteration process iteration where earlier stages are reworked in response to change request is always part of the process for large systems The iteration process models that have been designed to support process iteration?? –1- Incremental development (delivery) –2- Spiral development

34. 34 1- Incremental delivery It is an in between approach which combines the advantages of waterfall and evolutionary models. Rather than deliver the system as a single delivery, the software specification, design and implementation is broken down into increments with each increment delivering part of the required functionality.

35. 35 Incremental delivery User requirements are prioritized and the highest priority requirements are included in early increments Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve

36. 36 Incremental delivery advantages Customer can gain value from the system 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 The highest priority system services tend to receive the most testing it is useful when staffing is unavailable for a complete implementation.

37. 37 2- Spiral development Process is represented as a spiral rather than as a sequence of activities with backtracking from one activity to another. Each loop in the spiral represents a phase in the software process. The inner loop might be connected to feasibility, next loop with requirements definitions and so on. Risks are explicitly assessed and resolved throughout the process

38. 38 Spiral model of the software process

39. 39 Spiral model The main different between the Spiral model and other Software process model: is the explicit recognition of the risk (something that can be go wrong)

40. 40 Chapter 5 Project management

41. 41 5.2.2 Activity organization ( milestones and deliverables ) Milestones are the end-point of a process activity, the software process must be broken down into basic activities. At the end of each milestone there should be a formal output such as a report. Deliverables are project results delivered to customers deliverables are milestones but milestones need not be deliverables. Milestones are an internal project result used by manager to check project progress that are not delivered to customer

42. 42 5.3 Project scheduling Split project into tasks and estimate time and resources required to complete each task Organize tasks concurrently (simultaneously or side by side) to make optimal use of workforce. Minimize task dependencies to avoid delays caused by one task waiting for another to complete Dependent on project managers intuition and experience schedules must be continually updated as better progress info becomes available.

43. 43 Scheduling The maximum a mount of time of any activity is from 8-10 weeks. The minimum at least 1 week If it is larger than this, it must be divided.

44. 44 5.3.1 Bar charts and activity networks Graphical notations used to illustrate the project schedule Show project breakdown into tasks. Tasks should not be too small. They should take about a week or two Network Activity show task dependencies and the the critical path Bar charts show schedule against calendar time The minimum time required to finish the project is called the critical path, which it is the longest path in the activity graph.

45. 45 Task duration and dependencies Example: T3 start after T1 finish.

46. 46 Activity network for example, if T8 is delayed 2 weeks, it will not affect the completion date because it does not lie on critical path. The critical path is: T1  T3  T9  T11  T12The minimum days required to complete project is : 8+ 15+ 15+7+10 =55 day

47. 47 Activity timeline

48. 48 Staff allocation

49. 49 5.4 Risk management Risk management is concerned with identifying risks and drawing up plans to minimize their effect on a project.

50. 50 Risk management continues.. A risk is a probability that some adverse (unfavorable) circumstance will occur, such categories are: –Project risks affect schedule or resources. e.g. Loss of an experienced designer –Product risks affect the quality or performance of the software being developed. e.g. the failure of a purchased component. –Business risks affect the organization developing a software –e.g. a competitor introducing a new product

51. 51 Chapter 6 Software Requirements Part - 1

52. 52 Types of requirement (level of description) User requirements –Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for client and contractor managers. System requirements –A structured document setting out detailed descriptions of the system services and constraints in detail. Written as a contract between a system buyer and developer.

53. 53 Requirements completeness and consistency In principle requirements should be both complete and consistent –Complete means, they should include descriptions of all facilities required –Consistent means, there should be no conflicts or contradictions in the descriptions of the system facilities In practice, it is impossible to produce a complete and consistent requirements document

54. 54 Chapter 7 Requirements Engineering Processes Haya Sammaneh

55. 55 Topics covered Feasibility studies Requirements elicitation and analysis Requirements validation Requirements management

56. 56 c. Scenarios Scenarios are descriptions of how a system is used in practice, a real-life examples of how a system can be used. Scenarios are particularly useful for adding detail to an outline requirements description

57. 57 Event scenario - start transaction

58. 58 c. Use cases Use-cases are a scenario based technique for requirement elicitation in the UML notations that used in object-oriented system model (Unified Modelling Language) which identify the actors in an interaction and which describe the interaction itself A set of use cases should describe all possible interactions with the system Sequence diagrams may be used to add detail to use-cases by showing the sequence of event in the system

59. 59 Use cases, cont.. The sequence diagram (ch 6) is used to add information to use-case. The sequence diagram shows the: 1- actors used in the interaction 2- objects that the actors interact with. 3- operation associated with these objects.

60. 60 Library system, example. Interaction for downloading and printing article. Objects used in this interaction are: 1. Article 2. Form 3. workspace 4. printer

61. 61 Lending use-case

62. 62 use-cases for Library system

63. 63 Example of sequence diagram of Printing article.