Pertemuan 2. Software Engineering: The Process

Size: px

Start display at page:

Download "Pertemuan 2. Software Engineering: The Process"

Natalie Merritt
6 years ago
Views:

1 Pertemuan 2 Software Engineering: The Process

2 Collect Your Project Topic

3 What is Software Engineering? Software engineering is the establishment and sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines (Fritz Bauer,1969) Software engineering is [1] the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and [2] the study of approaches as in [1] (IEEE,1993) * SEPA 6 th ed, Roger S. Pressman

4 What is software engineering? i An engineering discipline which is concerned with all aspects of software production Engineering discipline Discover solutions by applying theories, methods or other mechanisms. Work within constraints All aspects of software production Software development (technical processes) Project management Development of supporting tools, methods and theories

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

6 The software process A structured set of activities (and associated results) required to develop (evolve) a software system Specification Design and implementation Validation ld Evolution A software process model is an abstract representation of a process. presents a description of a process from a particular perspective a simplified representation

7 The software process Software development is a complex process needing human jd judgement and creativity it therefore could not be fully automated There is no ideal software process Many diverse processes exist There is room for improvement! Organizations select software processes based on Organizations select software processes based on: capabilities of people in the organization characteristics of the system to be developed etc.

8 A Layered Technology Software Engineering Tools (The support) Methods (The How to ) process model (The glue and foundation) a quality focus (The commitment) * SEPA 6 th ed, Roger S. Pressman

9 Work Orientation* Need to be : Target Oriented Process Oriented Quality Oriented

10 Why SE? (1) To get the right software and to make the software right Complexity of software Domain problem: Business Rule Data size: Digital it and Non Digitalit Solution: Algorithm Place or Sites

11 Why SE? (2) Software must be correct Software correctness have to be maintained

12 How should SE be applied? There are 2 things to be considered in SE: Product = Software: Programs Documents Data Process of how the software is build: Management process Technical process

13 Product of SE Product is obtained through stages of development = Software Development Life Cycle (SDLC) Examples of life cycles (SDLC): Waterfall model V model Spiral model Fountain model Prototyping

14 Process of SE (1) Management process includes: Project management Configuration management Quality Assurance management

15 Process of SE (2) Technical process, described as methods to be applied in a particular stage of the s/w development life-cycle Analysis methods Design methods Programming methods Testing methods Technical methods are leading to paradigms

16 When should SE be applied? Pre project Project Initiation i i Project Realisation Software Delivery & Maintenance

17 Who is involved? Manager Project Manager Configuration Manager Quality Assurance Manager Software Developer: Analyst Designer Programmer

18 Who is involved? Who is involved? Support Administration Technical Support for Customer Welfare

19 What is the difference between software engineering and computer science? Computer science is concerned with theory and fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software. Computer science theories are still insufficient to act as a complete underpinning for software engineering. * Software Engineering 7 th ed, Ian Sommerville

20 What Is The Difference Between Software Engineering And System Engineering? System engineering is concerned with all aspects of computer based systems development including hardware, software and process engineering. Software engineering is part of this process concerned with developing the software infrastructure, control, applications and databases in the system. System engineers are involved in system specification, architectural design, integration and deployment. * Software Engineering 7 th ed, Ian Sommerville

21 Systems engineering i Specifying, designing, implementing, validating, deploying and maintaining socio technical systems. Concerned with Services provided d by the system Constraints on its construction and operation Ways in which it is used Software Hardware System interaction with users and environment

22 Systems engineering i Why does a software engineer need to understand system engineering aspects? Many software systems are part of a larger system System engineering gdecisions have direct impacts on software Many systems now have lots of software parts

23 Systems engineering i Systems have limited scope for rework during system development Decisions are expensive to change (e.g. hardware manufactured) Software on the other hand is flexible and allows change during system development Interdisciplinary involvement Many different disciplines i involved in system engineering i Increased possibility of misunderstanding due to different technologies and conventions used

24 What Are The Costs of Software Engineering? Roughly 60% of costs are development costs, 40% are testing costs. For custom software, evolution costs often exceed development costs. Costs vary depending on the type of system being developed and the requirements of system attributes such as performance and system reliability. Distribution of costs depends on the development model that is used. * Software Engineering 7 th ed, Ian Sommerville

25 What Are Software Engineering Methods? Structured approaches to software development which include system models, notations, rules, design advice and process guidance. Model descriptions Rules Descriptions of graphical models which should be produced; Constraints applied to system models; Recommendations Advice on good design practice; Process guidance What activities to follow. * Software Engineering 7 th ed, Ian Sommerville

27 Questions To Ask And Be Answered What is the problem What entities needed to solve the problems How will the entity (solution) be realised What approach used for detecting errors How to support the entity over time in relation to corrections, adaptations, and enhancements.

28 Software phases Definition Phase : information, functions/performances, behaviors, interfaces, constraints, and validation criteria Development Phase : data structure, function implementation, interface character, design programming, and testing Support Phase : error correction, adaptation, enhancement, prevention/re engineering g

29 Requirement justifications * Necessity : Need to have, nice to have, need not to have Feasibility : technically, economically, operationally

30 A Common Process Framework Framework activities tasks milestones & deliverables QA checkpoints Umbrella Activities Umbrella Activities

31 Umbrella Activities Software project management Formal technical reviews Software quality assurance Software configuration management Document preparation and production Reusability management Measurement Risk management

32 What is a 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 Waterfall Iterative development Formal transformation Integration from reusable components

33 Problem Solving Loop Model problem definition status quo technical development solution integration

34 Problem Solving Loop Model problem definition status quo technical development solution integration problem definition Status Quo status quo technical development problem definition solution integration status quo technical development solution integration

35 Problem Solving Loop Model Difficult to contain activity neatly Cross talks within and across stages Tasks (and degree of rigor) for each activity will vary based on: the type of project (an entry point to the model) characteristics of the project common sense judgment; concurrence of the project team

36 Generic software process models The waterfall model Separate and distinct t phases of specification and development Evolutionary development Specification, development and validation are interleaved Component based software engineering The system is assembled from existing components. There are many variants of these models formal development a waterfall like process is used but the specification is a formal specification that is refined through several stages to an implementable design.

37 Waterfall model Requirements definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance

38 Waterfall model phases Requirements analysis and definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance

39 Waterfall model Each stage produces documents at the end Next stage starts only after signing off the previous stage non overlapping stages (but in reality, they do overlap) A number of iterations e.g. requirement errors identified during design, go back and correct them Due to the high cost involved in rework, stages are frozen after a few iterations. ti problems identified later are left to be resolved later or worked around in programming may lead to badly structured systems

40 Waterfall Model Features

41 Waterfall model: advantages It is a well understood mature process Easy to manage projects Produces robust, well structured systems High process visibility

42 The Linear (Waterfall) Model Changes can create confusion Difficult to accommodate early stage natural uncertainty Working version can only be obtained later on

43 Waterfall Model Negative Characteristics

44 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 Requirement changes are limited

45 The Linear (Waterfall) Model Requirements Analysis : information, function, behavior, performance, and interface > Deliverable : SRS Document Design : data structure, t software architecture, t interface representation, tti algorithm. Deliverable : Software Configuration Code generation : deliverables : program code Testing : logical and functional Support : error correction, adaptation, enhancement

46 Waterfall Model Characteristics

47 Waterfall Model Document

48 Waterfall Model Fitness

49 Waterfall Model (Another Look)

50 Development Process Discussion Time to Market

51 Development Process Shorter Life Cycle

52 Prototyping Models listen to customer build/revise mock-up customer test-drives mock-up Prototyping

53 Prototyping Models Prototype serves as first system Can make customer demands of a few fixes to make a working product Implementation is compromised to get a prototype quickly. Need to agree that prototype only serves as mechanism for defining fii requirements

54 Prototyping Model Used in Combination with Waterfall Model

55 Prototyping

56 Evolutionary Prototyping

57 Throw away Prototyping

58 Revolutionary Development

59 RAD Models team #1 team #2 b u s i n e s s m o d e l i n g team #3 b u s i n e s s m o d e l i n g d a t a m o d e l i n g business modeling m d a t a o d e l i n g p r o c e s s m o d e l i n g a p p l i c a t i o n g e n e r a t i o n data modeling p r o c e s s m o d e l i n g te s tin g & tu rn o v e r process modeling a p p l i c a t i o n g e n e r a t i o n t e s t i n g & tu r n o v e r application generation testing & turnover days RAD

60 The RAD Model Business Modelling : BPM (what info needed, who generate it, who use it,etc), BPR Data Modelling : data objects, attributes, and relationship Process Modelling : add, modify, delete, retrieve data object Application Generation : reuse and /or create reusable components Testing and turnover : newly created components

61 The RAD Model Requires substantial resources for large projects Requires commitment of developers and customers. Not suitable for high risk and performance applications (high degree of interoperability)

62 The Incremental Model System/information engineering increment 1 analysis design code test delivery of 1st increment increment 2 analysis design code test delivery of 2nd increment increment 3 analysis design code test delivery of 3rd increment increment 4 analysis design code test delivery of 4th increment calendar time

63 The Incremental Model First increment = core product Subsequent increments = additional features and functions Useful for under staff situation to meet dateline

64 Incremental development 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 But requirements for later increments can continue to evolve

65 Incremental development Define outline requirements Assign requirements to increments Design system architecture Develop system increment Validate increment System incomplete Integrate increment Validate system Final system

66 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 Different processes can be used for increments Disadvantages Difficult to map user requirements into increments which can deliver functionality Difficult to identify small increments (<20,000 LOC) Difficulty of identifying the common facilities needed by all sub systems

67 Spiral model of the software process Determine objectives alternatives and constraints Plan next phase REVIEW Requirements plan Life-cycle plan Development plan Integration and test plan Risk analysis Risk analysis Risk analysis Prototype 2 Risk analysis Prototype 1 Concept of Operation Requirement validation Design V&V Service S/W requirements Acceptance test Operational protoype Evaluate alternatives identify, resolve risks Prototype 3 Simulations, models, benchmarks Product design Code Unit test Integration test Detailed design Develop, verify next-level product

68 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 Develop and validate the system in the current phase Planning The project is reviewed and the next phase of the spiral is planned

69 The Spiral Model Start from center clockwise Each pass = next stage of project : e.g. Concept development, product development, product enhancement Realistic approach to large scale system development Better understanding and reaction to risk Requires expertise in risk assessment Not widely used

70 Spiral development 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 Ri k li itl d d l d th h t th Risks are explicitly assessed and resolved throughout the process

71 Spiral model Identifies probable risks in advance and tries to minimize them e.g. if it is decided to use a new programming language, the compilers available may not be reliable Occurrence of a risk item could result in project delay, exceeding cost or even failure Different processes maybe used for different loops in the spiral

72 Component Based Model Identify Candidate component Customer Communication P la nn in g Risk Analysis Construct iteration of system Look up component in library Engineering i Put new component in library Extract component if available Customer Evaluation Construction & Release Build component if unavailable

73 The Component based Model process to apply when reuse is a development objective Unified Modeling Language (UML) for defining components to use and interfaces that connect the components

74 V Model

75 V Model Document Produced

76 The 4 th Generation Techniques Ability to specify software characteristics at high level Includes : code generation, report generation, data manipulation, HTML generation, etc Offers credible solutions to software problems Reduction amount of design and analysis Requires more analysis, design, and testing of software

77 Component based software engineering Reuse occurs informally in almost all software projects 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

78 Component based software engineering.. Requirements specification Component analysis Requirements modification System design with reuse Development and integration System validation

79 Component based software engineering.. Advantages reduces the amount of software to develop reduces cost and risks faster delivery Disadvantages requirement compromises lose control of system evolution (because component evolution is not controllable)

80 Formal systems development Based on the transformation of a mathematical specification through different representations to an executable program Transformations are correctness preserving so it is straightforward to show that the program conforms to its specification Design, implementation and unit testing phases are replaced g, p g p p by a transformational development process

81 Formal systems development Requirements Formal Formal Integration and definition specification transformation system testing (iterations have been excluded)

82 Formal transformations Formal transformations T1 T2 T3 T4 Formal specification R1 R2 R3 Executable program P1 P2 P3 P4 Proofs of transformation correctness

83 Formal systems development Problems Need for specialised skills and training to apply the technique Difficult to formally specify some aspects of the system such as the user interface Applicability Critical systems especially those where a safety, reliability and security requirements are important e.g. Patient monitoring system, airplane engine control system

84 Process iteration and hybrid models LARGE SYSTEMS need different approaches for different parts System requirements always evolve during a project So process iteration ti where earlier stages are reworked kd is always part of the process for large systems Two (related) approaches pp Incremental development Spiral development

85 Still Other Process Models Concurrent process model recognizes that different part of the project will be at different places in the process Formal methods the process to apply when a mathematical specification is to be developed Clean room software engineering emphasizes error detection before testing

86 The Primary Goal: High Quality Remember: High quality = project timeliness Why? Less rework!

87 CMM I (Capability Maturity Model Integrated) * Initial i : ad hoc process, sometimes chaotic, success depends d on individuals id Repeatable : basic PM to track cost, schedule and functionality, posses necessary process discipline to repeat earlier success. Defined : process are documented, standardized and integrated Managed : detailed measures and product quality are collected. Both process and products are understood and controlled using detailed measures. Managed : detailed measures and product quality are collected. Both process and products are understood and controlled using detailed measures. Success is probable Optimizing : continuous process trough feedback. Success is always

88 What is CASE (Computer Aided d Software Engineering) i Software systems that are intended to provide automated support for software process activities. iti 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. * Software Engineering 7 th ed, Ian Sommerville

Software Processes. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1

Software Processes. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1 Objectives To introduce software process models To describe three generic process models and when they may be