Software Engineering

1. Software Engineering Young S. Cho Department of Computer Science and Multimedia Engineering

2. Software Engineering • Introduction • Software Processes • Project Planning • Software Requirements • Design • Development • Verification and Validation • Testing and Debugging • Project Management

3. Chapter 1:Introduction Software, Program, and System Program vs. Software What is Software? What is a System? Software Crisis Software Engineering Systems Engineering Software Engineering vs. Systems Engineering Software Characteristics

4. Software, Program, and System • Program vs. Software • Program: an ordered set of instructions to solve a specific problem. • Software: Computer programs and associated documentation such as requirements, design models and user manuals.

5. What is Software? • Software products may be developed for a particular customer or may be developed for a general market. • Software products may be • Generic - developed to be sold to a range of different customers e.g. PC software such as Excel or Word. • Bespoke (custom) - developed for a single customer according to their specification. • New software can be created by developing new programs, configuring generic software systems or reusing existing software. • Computer programs and associated documentation such as requirements, design models and user manuals.

6. What is a system? • A purposeful collection of inter-related components working together to achieve some common objective. • A system may include software, mechanical, electrical and electronic hardware and be operated by people. • System components are dependent on other system components. • The properties and behaviour of system components are inextricably inter-mingled.

7. Software Crisis • The size of software has grown explosively. • The complexity of software applications has expanded. • The nature of software applications has become more critical. • The demand for qualified software professionals has increased. • As the result, software cost has highly increased. • Software development tools and methodologies have not continued to dramatically improve the ability to develop software.

8. Software Engineering • Software engineering is an engineering discipline that is concerned with all aspects of software production. • Software engineers should adopt a systematic and organised approach to their work and use appropriate tools and techniques depending on the problem to be solved, the development constraints and the resources available. • The economies of ALL developed nations are dependent on software.

9. Software Engineering (cont’d) • More and more systems are software controlled. • Software engineering is concerned with theories, methods and tools for professional software development. • Expenditure on software represents a significant fraction of GNP in all developed countries. • The aim is to improve both software development productivity and software quality.

10. Systems Engineering • Specifying, designing, implementing, validating, deploying and maintaining socio-technical systems. • Concerned with the services provided by the system, constraints on its construction and operation and the ways in which it is used.

11. Software Engineering vs. Systems Engineering • Systems engineering is concerned with all aspects of computer-based systems development including hardware, software and process engineering. • System engineers are involved in system specification, architectural design, integration and deployment. • Software engineering is part of this process concerned with developing the software infrastructure, control, applications and databases in the system.

12. Software Characteristics • Software is engineered. • Software doesn’t wear out. • Software is complex.

13. Wear vs. Deterioration

14. Attributes of Good Software • The software should deliver the required functionality and performance to the user and should be maintainable, dependable and acceptable. • Maintainability: Software must evolve to meet changing needs. • Dependability: Software must be trustworthy. • Efficiency: Software should not make wasteful use of system resources. • Acceptability: Software must accepted by the users for which it was designed. This means it must be understandable, usable and compatible with other systems.

15. Chapter 2:Software Processes Software Process, Models, and Tools Software Process Models

16. The Software Process • A structured set of activities required to develop or to maintain a software system • Specification; • Design and implementation; • Validation; • Evolution. • A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective.

17. Software Specification • The process of establishing what services are required and the constraints on the system’s operation and development. • Requirements engineering process • Feasibility study; • Requirements elicitation and analysis; • Requirements specification; • Requirements validation.

18. Software Design and Implementation • The process of converting the system specification into an executable system. • Software design • Design a software structure that realises the specification; • Implementation • Translate this structure into an executable program; • The activities of design and implementation are closely related and may be inter-leaved.

19. Programming, Testing, and Debugging • Programming: Translate a design into a program. • Testing: Uncover (discover) errors. • Debugging: Remove errors from the program. • Programming is a personal activity - there is no generic programming process. • Programmers carry out some program testing to discover faults in the program and remove these faults in the debugging process.

20. Software Validation • Verification and validation (V & V) is intended to show that a system conforms to its specification and meets the requirements of the system customer. • Involves checking and review processes and system testing. • System testing involves executing the system with test cases that are derived from the specification of the real data to be processed by the system.

21. Testing Stages • Component or unit testing • Individual components are tested independently; • Components may be functions or objects or coherent groupings of these entities. • System testing • Testing of the system as a whole. Testing of emergent properties is particularly important. • Acceptance testing • Testing with customer data to check that the system meets the customer’s needs.

22. Software Evolution • Software is inherently flexible and can change. • As requirements change through changing business circumstances, the software that supports the business must also evolve and change. • Although there has been a demarcation between development and evolution (maintenance) this is increasingly irrelevant as fewer and fewer systems are completely new.

23. Software Process Model • A simplified representation of a software process, presented from a specific perspective. • Examples of process perspectives are • Workflow perspective - sequence of activities; • Data-flow perspective - information flow • Role/action perspective - who does what. • Generic process models: • The Waterfall model • Iterative development models • Component-based software engineering

24. Software Process Models • The waterfall model • Separate and distinct phases of specification and development. • Component-based software engineering: The system is assembled from existing components. • Prototyping Model • RAD Model • Evolutionary Software Process Models: Specification, development and validation are interleaved. • Evolutionary Development • Throw-away Prototyping • Incremental Model • Spiral Model • Agile Process • XP (Extreme Programming) • Reuse-oriented Model • Formal Method Model

25. Waterfall Model

26. Waterfall Model Phases • Requirements analysis and definition • System and software design • Implementation and unit testing • Integration and system testing • Operation and maintenance • The main drawback of the waterfall model is the difficulty of accommodating change after the process is underway. One phase has to be complete before moving onto the next phase.

27. Waterfall Model Problems • Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements. • Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process. • Few business systems have stable requirements. • The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites.

28. Component-Based Software Engineering • Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems. • Process stages • Component analysis; • Requirements modification; • System design with reuse; • Development and integration. • This approach is becoming increasingly used as component standards have emerged.

29. Prototyping Model • Throw-away prototyping • Objective is to understand the system requirements. Should start with poorly understood requirements to clarify what is really needed. • Prototyping as an Evolutionary Model: • Communication • Quick Plan • Modeling and Quick Design • Construction of Prototype • Deployment Delivery and Feedback • Go to 1 until Finish

30. Prototyping • For some large systems, incremental iterative development and delivery may be impractical; this is especially true when multiple teams are working on differentsites. • Prototyping, where an experimental system is developed as a basis for formulating the requirements may be used. This system is thrown away when the system specification has been agreed.

31. Rapid Software Development • Because of rapidly changing business environments, businesses have to respond to new opportunities and competition. • This requires software and rapid development and delivery is not often the most critical requirement for software systems. • Businesses may be willing to accept lower quality software if rapid delivery of essential functionality is possible.

32. Rapid Application Development • Agile methods have received a lot of attention but other approaches to rapid application development have been used for many years. • These are designed to develop data-intensive business applications and rely on programming and presenting information from a database.

33. RAD Environment Tools • Database programming language • Interface generator • Links to office applications • Report generators

34. Evolutionary Development • Exploratory development • Objective is to work with customers and to evolve a final system from an initial outline specification. Should start with well-understood requirements and add new features as proposed by the customer. • Throw-away prototyping • Objective is to understand the system requirements. Should start with poorly understood requirements to clarify what is really needed.

35. Evolutionary Development (cont’d)

36. Evolutionary Development (cont’d) • Problems • Lack of process visibility; • Systems are often poorly structured; • Special skills (e.g. in languages for rapid prototyping) may be required. • Applicability • For small or medium-size interactive systems; • For parts of large systems (e.g. the user interface); • For short-lifetime systems.

37. Incremental 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 though requirements for later increments can continue to evolve.

38. Incremental Development

39. Incremental Development • Advantages • 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. • The highest priority system services tend to receive the most testing.

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

41. Spiral Model: Software Process

42. Spiral Model Sectors • Objective setting • Specific objectives for the phase are identified. • Risk assessment and reduction • Risks are assessed and activities put in place to reduce the key risks. • Development and validation • A development model for the system is chosen which can be any of the generic models. • Planning • The project is reviewed and the next phase of the spiral is planned.

43. Agile Process • Is driven by customer descriptions of what is required (scenarios) • Recognizes that plans are short-lived • Develops software iteratively with a heavy emphasis on construction activities • Delivers multiple ‘software increments’ • Adapts as changes occur

44. What is Agility? • Effective (rapid and adaptive) response to change • Effective communication among all stakeholders • Drawing the customer onto the team • Organizing a team so that it is in control of the work performed Yielding … • Rapid, incremental delivery of software

45. Manifesto for Agile Software Development • “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan • That is, while there is value in the items on the right, we value the items on the left more.” Kent Beck et al

46. Agile Modeling • Originally proposed by Scott Ambler • Suggests a set of agile modeling principles • Model with a purpose • Use multiple models • Travel light • Content is more important than representation • Know the models and the tools you use to create them • Adapt locally

47. Extreme Programming (XP) • An approach to development based on the development and delivery of very small increments of functionality • Relies on constant code improvement, user involvement in the development team and pairwise programming.

48. Extreme Programming (cont’d) • The most widely used agile process, originally proposed by Kent Beck • XP Planning • XP Design • XP Coding • XP Testing

49. Extreme Programming (cont’d) • XP Planning • Begins with the creation of “user stories” • Agile team assesses each story and assigns a cost • Stories are grouped to for a deliverable increment • A commitment is made on delivery date • After the first increment “project velocity” is used to help define subsequent delivery dates for other increments • XP Design • Follows the KIS principle • Encourage the use of CRC cards • For difficult design problems, suggests the creation of “spike solutions”—a design prototype • Encourages “refactoring”—an iterative refinement of the internal program design

50. Extreme Programming (cont’d) • XP Coding • Recommends the construction of a unit test for a store before coding commences • Encourages “pair programming” • XP Testing • All unit tests are executed daily • “Acceptance tests” are defined by the customer and executed to assess customer visible functionality