Lectures-combined.pdf Software Processes PDF

Chapter 2 – Software Processes Lecture 1 Chapter 2 Software Processes 1 Topics covered  Software process models  Process activities  Coping with change  The Rational Unified Process ▪ An example of a modern software process. Chapter 2 S...

Chapter 2 – Software Processes Lecture 1 Chapter 2 Software Processes 1 Topics covered  Software process models  Process activities  Coping with change  The Rational Unified Process ▪ An example of a modern software process. Chapter 2 Software Processes 2 The software process  A structured set of activities required to develop a software system.  Many different software processes but all involve: ▪ Specification – defining what the system should do; ▪ Design and implementation – defining the organization of the system and implementing the system; ▪ Validation – checking that it does what the customer wants; ▪ Evolution – changing the system in response to changing customer needs.  A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective. Chapter 2 Software Processes 3 Software process descriptions  When we describe and discuss processes, we usually talk about the activities in these processes such as specifying a data model, designing a user interface, etc. and the ordering of these activities.  Process descriptions may also include: ▪ Products, which are the outcomes of a process activity; ▪ Roles, which reflect the responsibilities of the people involved in the process; ▪ Pre- and post-conditions, which are statements that are true before and after a process activity has been enacted or a product produced. Chapter 2 Software Processes 4 Plan-driven and agile processes  Plan-driven processes are processes where all of the process activities are planned in advance and progress is measured against this plan.  In agile processes, planning is incremental and it is easier to change the process to reflect changing customer requirements.  In practice, most practical processes include elements of both plan-driven and agile approaches.  There are no right or wrong software processes. Chapter 2 Software Processes 5 Software process models  The waterfall model ▪ Plan-driven model. Separate and distinct phases of specification and development.  Incremental development ▪ Specification, development and validation are interleaved. May be plan-driven or agile.  Reuse-oriented software engineering ▪ The system is assembled from existing components. May be plan-driven or agile.  In practice, most large systems are developed using a process that incorporates elements from all of these models. Chapter 2 Software Processes 6 The waterfall model Chapter 2 Software Processes 7 Waterfall model phases  There are separate identified phases in the waterfall model: ▪ 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. In principle, a phase has to be complete before moving onto the next phase. Chapter 2 Software Processes 8 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. ▪ In those circumstances, the plan-driven nature of the waterfall model helps coordinate the work. Chapter 2 Software Processes 9 Incremental development Chapter 2 Software Processes 10 Incremental development benefits  The cost of accommodating changing customer requirements is reduced. ▪ The amount of analysis and documentation that has to be redone is much less than is required with the waterfall model.  It is easier to get customer feedback on the development work that has been done. ▪ Customers can comment on demonstrations of the software and see how much has been implemented.  More rapid delivery and deployment of useful software to the customer is possible. ▪ Customers are able to use and gain value from the software earlier than is possible with a waterfall process. Chapter 2 Software Processes 11 Incremental development problems  The process is not visible. ▪ Managers need regular deliverables to measure progress. If systems are developed quickly, it is not cost-effective to produce documents that reflect every version of the system.  System structure tends to degrade as new increments are added. ▪ Unless time and money is spent on refactoring to improve the software, regular change tends to corrupt its structure. Incorporating further software changes becomes increasingly difficult and costly. Chapter 2 Software Processes 12 Reuse-oriented 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.  Reuse is now the standard approach for building many types of business system ▪ Reuse covered in more depth in Chapter 16. Chapter 2 Software Processes 13 Reuse-oriented software engineering Chapter 2 Software Processes 14 Types of software component  Web services that are developed according to service standards and which are available for remote invocation.  Collections of objects that are developed as a package to be integrated with a component framework such as.NET or J2EE.  Stand-alone software systems (COTS) that are configured for use in a particular environment. Chapter 2 Software Processes 15 Process activities  Real software processes are inter-leaved sequences of technical, collaborative and managerial activities with the overall goal of specifying, designing, implementing and testing a software system.  The four basic process activities of specification, development, validation and evolution are organized differently in different development processes. In the waterfall model, they are organized in sequence, whereas in incremental development they are inter- leaved. Chapter 2 Software Processes 16 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 Is it technically and financially feasible to build the system? ▪ Requirements elicitation and analysis What do the system stakeholders require or expect from the system? ▪ Requirements specification Defining the requirements in detail ▪ Requirements validation Checking the validity of the requirements Chapter 2 Software Processes 17 The requirements engineering process Chapter 2 Software Processes 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. Chapter 2 Software Processes 19 A general model of the design process Chapter 2 Software Processes 20 Design activities  Architectural design, where you identify the overall structure of the system, the principal components (sometimes called sub-systems or modules), their relationships and how they are distributed.  Interface design, where you define the interfaces between system components.  Component design, where you take each system component and design how it will operate.  Database design, where you design the system data structures and how these are to be represented in a database. Chapter 2 Software Processes 21 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.  Testing is the most commonly used V & V activity. Chapter 2 Software Processes 22 Stages of testing Chapter 2 Software Processes 23 Testing stages  Development or component 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. Chapter 2 Software Processes 24 Testing phases in a plan-driven software process Chapter 2 Software Processes 25 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. Chapter 2 Software Processes 26 System evolution Chapter 2 Software Processes 27 Key points  Software processes are the activities involved in producing a software system. Software process models are abstract representations of these processes.  General process models describe the organization of software processes. Examples of these general models include the ‘waterfall’ model, incremental development, and reuse-oriented development. Chapter 2 Software Processes 28 Key points  Requirements engineering is the process of developing a software specification.  Design and implementation processes are concerned with transforming a requirements specification into an executable software system.  Software validation is the process of checking that the system conforms to its specification and that it meets the real needs of the users of the system.  Software evolution takes place when you change existing software systems to meet new requirements. The software must evolve to remain useful. Chapter 2 Software Processes 29 Coping with change  Change is inevitable in all large software projects. ▪ Business changes lead to new and changed system requirements ▪ New technologies open up new possibilities for improving implementations ▪ Changing platforms require application changes  Change leads to rework so the costs of change include both rework (e.g. re-analysing requirements) as well as the costs of implementing new functionality Chapter 2 Software Processes 30 Reducing the costs of rework  Change avoidance, where the software process includes activities that can anticipate possible changes before significant rework is required. ▪ For example, a prototype system may be developed to show some key features of the system to customers.  Change tolerance, where the process is designed so that changes can be accommodated at relatively low cost. ▪ This normally involves some form of incremental development. Proposed changes may be implemented in increments that have not yet been developed. If this is impossible, then only a single increment (a small part of the system) may have be altered to incorporate the change. Chapter 2 Software Processes 31 Software prototyping  A prototype is an initial version of a system used to demonstrate concepts and try out design options.  A prototype can be used in: ▪ The requirements engineering process to help with requirements elicitation and validation; ▪ In design processes to explore options and develop a UI design; ▪ In the testing process to run back-to-back tests. Chapter 2 Software Processes 32 Benefits of prototyping  Improved system usability.  A closer match to users’ real needs.  Improved design quality.  Improved maintainability.  Reduced development effort. Chapter 2 Software Processes 33 The process of prototype development Chapter 2 Software Processes 34 Prototype development  May be based on rapid prototyping languages or tools  May involve leaving out functionality ▪ Prototype should focus on areas of the product that are not well- understood; ▪ Error checking and recovery may not be included in the prototype; ▪ Focus on functional rather than non-functional requirements such as reliability and security Chapter 2 Software Processes 35 Throw-away prototypes  Prototypes should be discarded after development as they are not a good basis for a production system: ▪ It may be impossible to tune the system to meet non-functional requirements; ▪ Prototypes are normally undocumented; ▪ The prototype structure is usually degraded through rapid change; ▪ The prototype probably will not meet normal organisational quality standards. Chapter 2 Software Processes 36 Incremental delivery  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. Chapter 2 Software Processes 37 Incremental development and delivery  Incremental development ▪ Develop the system in increments and evaluate each increment before proceeding to the development of the next increment; ▪ Normal approach used in agile methods; ▪ Evaluation done by user/customer proxy.  Incremental delivery ▪ Deploy an increment for use by end-users; ▪ More realistic evaluation about practical use of software; ▪ Difficult to implement for replacement systems as increments have less functionality than the system being replaced. Chapter 2 Software Processes 38 Incremental delivery Chapter 2 Software Processes 39 Incremental delivery 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. Chapter 2 Software Processes 40 Incremental delivery problems  Most systems require a set of basic facilities that are used by different parts of the system. ▪ As requirements are not defined in detail until an increment is to be implemented, it can be hard to identify common facilities that are needed by all increments.  The essence of iterative processes is that the specification is developed in conjunction with the software. ▪ However, this conflicts with the procurement model of many organizations, where the complete system specification is part of the system development contract. Chapter 2 Software Processes 41 Lecture Software Process Definition and Management Chapter 1: Introduction Dr. Jürgen Münch Fall 2012 Software Process Definition and Management - Chapter 1 Software Project Challenges Introduction Administrative Product quality poor – but what should we change to fix this? Information e.g., when do we introduce most bugs – and when should we Objectives find them? Motivation Software Process Deadlines missed – but where do we lose all that time? Modeling and Improvement e.g., do we lose most time during requirements negotiation, Process Modeling or during testing? Goals and Benefits Budget overruns – but what are the most expensive activities? Terminology Summary e.g., are we spending most effort on coding or on rework? Overhead – why do we spend so much effort on non-productive activities? e.g., how much time is consumed by collecting information? New employees – how should they learn how we work? e.g., through trial & error or by some more efficient means? Slide 2 Software Process Definition and Management - Chapter 1 Information Needs Introduction Administrative What information do we need to answer these questions? Information Which activities are performed in which sequence? Objectives Motivation Which are the inputs and outputs of these activities? Software Process Who is involved in a specific activity? Modeling and Improvement How long does it take to complete an activity? Process Modeling Are specific people bottlenecks? Goals and Benefits Terminology How do the activities contribute to higher-level goals? Summary … How can we gather the required information? We need a precise and concise model of the process that holds the required information If you don’t know where you are, a map won’t help! (Watts Humphrey) Slide 3 Software Process Definition and Management - Chapter 1 Working in a Team Introduction Administrative Principles and difficulties of team-oriented working Information Sharing of tasks among specialists Objectives Motivation Parallel working Software Process Relations between tasks Modeling and Improvement Dead ends, contrary viewpoints between the members of the Process Modeling team Goals and Benefits Terminology Team leadership Summary Synchronization (e.g., coping with late requirements) Process requirements, not just product requirements Coping with these difficulties requires a description of what process is being followed! Slide 4 Software Process Definition and Management - Chapter 1 Software Process Models and the Context Introduction Administrative The characteristics of the environment, the context, determines Information which process models are the most appropriate for the given Objectives situation Motivation Software Process Context factors Modeling and Team experience Improvement Process Modeling Application domain Goals and Benefits Available budget Terminology Summary Non-functional quality requirements for the system Reliability Accuracy Security Cost Process models need to be tailored for the context and improvement needs to be context-specific Slide 5 Software Process Definition and Management - Chapter 1 Selected Benefits of Process Models Introduction Administrative Better transparency of software development activities Information Objectives Motivation external Software Process Who is responsible? Modeling and Coordination Who collaborates with Improvement whom? Process Modeling in the project Planning Goals and Benefits Who has to be informed? Terminology Management Summary Reduces complexity of large development efforts Process models are prerequisites for process assessment Process measurement & improvement requires process models Prerequisite for reaching predictability (e.g., with respect to completion date, quality); only achievable with explicit models! Slide 6 Software Process Definition and Management - Chapter 1 Process Modeling Terminology Introduction Software process modeling is quite a young research area Administrative Information Terminology is not mature yet Objectives parallel developments Motivation (e.g., development of different modeling notations) Software Process Modeling and influences from other research areas Improvement (e.g., business process modeling, programming languages, Process Modeling Petri nets) Goals and Benefits Terminology influence of standards and tools Summary (e.g., Software Engineering Process Meta-Model [SPEM], UML, ARIS) The semantic of terms if often determined by the context Organizations often have different names for similar constructs (e.g., activity, task, work assignment, work package, step,...) Mixture of model world and real world (e.g., usage of “process“ instead of “process model“) Unspecified domain (e.g., usage of “process“ instead of “software process“) Slide 7 Software Process Definition and Management - Chapter 1 Definition: Software Process Introduction Administrative Software (Development) Process := Information goal-oriented activity (such as the creation of a product or any Objectives other task) in the context of engineering-style software Motivation development Software Process Modeling and Enactment in the real world Improvement Example: coding of system component no. 15 in project Process Modeling Goals and Benefits Alpha at company ACSoft Terminology Usually transforms one or more input products by consuming Summary further products (e.g., coding guidelines) into one or more output products Can be performed by humans (“enactment“) or machines (“execution“) or both together As a refinement, processes can have a set of sub-processes, each of which can also be refined Can be part of a system development process Can be refined Slide 8 Software Process Definition and Management - Chapter 1 Definition: Project and Phase Introduction Administrative Project := Information unique endeavor, which is limited by a start date and an end date Objectives and should achieve a (set of) goal(s) Motivation Software Process Modeling and Project Phase (short: Phase) := Improvement a collection of logically separated project activities, usually Process Modeling Goals and Benefits culminating in the completion of a major deliverable or the Terminology achievement of a major milestone Summary Phases are mainly completed sequentially, but can overlap in some project situations Phases can be subdivided into sub-phases Unlike a process, a phase is always defined by a start and an end. If this period is finished, the phase is finished Processes can be activated multiple times Slide 9 Software Process Definition and Management - Chapter 1 Quotes Introduction Administrative Process: “A set of partially ordered steps intended to reach a Information goal.” Objectives [Feiler and Humphrey, Software Process Development and Motivation Enactment: Concepts and Definitions] Software Process Modeling and Improvement Process Modeling Goals and Benefits Terminology Summary Slide 10 Software Process Definition and Management - Chapter 1 Example Process Model Introduction Administrative Information 27. Integration Test Customer Data Objectives (Host) Tools Motivation Software Process APS Modeling and Improvement TSPA (from P3) 30. Customer Process Modeling Data Upgrade/ Tool- Test Goals and Benefits Protocol Upgrade Specification Terminology Summary 28. Integration Test Customer Data (Target) Data Delta Conformance Regression Test Cases Test Cases Slide 11 Software Process Definition and Management - Chapter 1 Elements of Process Models Introduction Administrative Identifiable activity or a group of activities Information Objectives Motivation Product flow (input and output products for activities) Software Process Modeling and Improvement Control flow between processes (enactment or execution Process Modeling sequence) Goals and Benefits Terminology Summary Refinement (hierarchy of processes) Relationships to techniques, methods, tools Relationships to roles Slide 12 Software Process Definition and Management - Chapter 1 Definition: Process Step and Enactment Introduction Administrative Process Step (synonym: elementary process) := Information An atomic process, which does not allow further structuring in Objectives the form of sub-processes. Motivation Software Process Modeling and Improvement Process Enactment := Process Modeling The performance of process steps undertaken to reach a Goals and Benefits given goal. The performer (i.e., ‘agent’) can be a human or a Terminology Summary machine. In case of a machine, the term ‘process execution’ is usually used. Slide 13 Software Process Definition and Management - Chapter 1 Definition: Process Definition, Script, and Program Introduction Administrative Process Definition := Information A description of a process that is executable Objectives Motivation Process scripts and process programs are specializations of Software Process process definitions Modeling and Improvement Process Modeling Process Script := Goals and Benefits Terminology A description of a process that is suitable for interpretation by Summary humans A process script should be tailored to the needs of the process performer. Process Program := A description of a process that can be interpreted by machines Slide 14 Software Process Definition and Management - Chapter 1 Example of a Process Script Introduction “Modify Test Plans” Administrative Description Information Objectives This step involves the modification of test plans and objectives to Motivation include testing of capabilities related to the requirements change Software Process prompting this software modification. [...] Modeling and [The test plans] identify the functionality and capabilities to be Improvement tested, and the approach to be taken. Process Modeling On the other hand, the specifics of actual test data, procedures, and Goals and Benefits so forth are dealt with in the subsequent step (modify unit test Terminology package). Summary Inputs Current test plans (from test plans file) [...] Outputs Modified test plans (to test plans file) [...] Responsibility This step is carried out by the assigned QA engineer. Constraints This step can begin as soon as the task has been assigned by the project manager. This step ends when its output has been provided. [Excerpt taken from ISPW-6 Software Process Example] Slide 15 Software Process Definition and Management - Chapter 1 Example of a Process Program Introduction Administrative Information TYPEPROCESS release Objectives Motivation 1 EVENT ready = ( state := ready ) ; Software Process Modeling and ROLE USER = PManager; Improvement Process Modeling ROLE implement = development; Goals and Benefits Terminology ROLE valid = validation; Summary ROLE component = module ; { ON ready DO { 2 IF implement.to_change.%name.state == ready THEN 3 implement.to_change.%name.state := available;... Slide 16 Software Process Definition and Management - Chapter 1 Definition: Process Schema Introduction Administrative Process Schema (synonym: process metamodel, process Information architecture):= a conceptual framework for the consistent Objectives description of process models and their relations Motivation Software Process A process schema describes Modeling and building blocks that form a process model, and Improvement Process Modeling constraints on their composition Goals and Benefits Only few process management tools are flexible enough to Terminology Summary cope with multiple process schemata or are able to import individual process schema Often, a process schema is created ad hoc together with the process model; this often implies description failures (e.g., phases are refined by processes) Slide 17 Software Process Definition and Management - Chapter 1 How to define a process? Introduction Administrative Example sequence for the definition of processes (heuristic): Information Identification of products and their refinements Objectives Motivation Identification of processes and their refinements Software Process Definition of product flows Modeling and Improvement Definition of control flow Process Modeling Assignment of techniques / methods / tools Goals and Benefits Terminology Generation of process documentation Summary (e.g., web-based description, handbook, training material) This is a concept-oriented approach There are other approaches (e.g., role-oriented, abstraction- oriented, control-flow-oriented) Slide 18 Software Process Definition and Management - Chapter 1 Definition: Process Performer, Owner, and Engineer Introduction Process Performer (or Agent) := Administrative Information Person or machine that enacts/executes the process in order to Objectives reach the process goal(s) Motivation Humans interpret process scripts, machines interpret process Software Process programs Modeling and Improvement Process Owner := Process Modeling Human or organizational entity that sets the goals of a process Goals and Benefits and is responsible for its achievement Terminology A process owner provides resources for the Summary enactment/execution of the process, but he/she is not responsible for providing process definitions Process Engineer := Person who has to fulfill one or several goals of process modeling (e.g., process definition for guiding developers) To that end, a process engineer uses process models, which he defines, extends, improves, and manages The process engineer should pay attention to the accuracy of the model, i.e., the correspondence between the real world process enactment/execution and the process model Slide 19 Software Process Definition and Management - Chapter 1 Definition: Product and Product Model Introduction Administrative Product (or Artifact) := Information Each artifact that is consumed or produced in the context of Objectives engineering-style software development Motivation Software Process Products can be refined by other products Modeling and Improvement Process Modeling (Software) Product Model := Goals and Benefits Terminology Description of (software) product or a class of (software) Summary products Usually, software product models consist of a description of the information units of a software product (e.g., functional requirements, non-functional requirements, design decisions) and a structure for arranging the information units (e.g., a table of contents for a requirements document) Slide 20 Software Process Definition and Management - Chapter 1 Product Examples Introduction Administrative Source code Information Specification document Objectives Motivation Problem description Software Process Configuration data Modeling and Improvement Component design Process Modeling Test cases and test results Goals and Benefits Terminology Project plan Summary... Slide 21 Software Process Definition and Management - Chapter 1 Definition: Product Flow Introduction Administrative Product Flow := Information Relationships between products and processes that describe Objectives the access mode to the products: Motivation Software Process produce (write/read) Modeling and Improvement consume (read) Process Modeling modify (read/write) Goals and Benefits Terminology Summary Slide 22 Software Process Definition and Management - Chapter 1 Example Graphical Representation (used e.g., in MVP-L) Introduction Administrative Information Objectives Motivation Software Process Process Modeling and Agent Improvement Process Modeling Goals and Benefits Terminology Summary Product Product flow Slide 23 Software Process Definition and Management - Chapter 1 Process Model with Product Flow Introduction Administrative Information Objectives Motivation Software Process Modeling and Improvement Process Modeling Goals and Benefits Terminology Summary Slide 24 Software Process Definition and Management - Chapter 1 Process Model with Product and Control Flow and Roles Introduction Administrative Information Objectives Motivation Software Process Modeling and Improvement Process Modeling Goals and Benefits Terminology Summary Slide 25 Software Process Definition and Management - Chapter 1 Definition: The Role Concept Introduction Administrative Role := Information A set of processes belonging together that are assigned to Objectives one or several agents Motivation Software Process A role combines the functional responsibility for the Modeling and enactment of a process Improvement Process Modeling Goals and Benefits Examples: Terminology Summary Designer Tester Quality Manager Product Manager Project Manager Slide 26 Software Process Definition and Management - Chapter 1 The Concept of a Role Introduction Administrative As a process, a role is an abstraction Information Simplification Objectives Motivation Grouping of competencies (knowledge & rights) Software Process Relationships between roles and agents Modeling and Improvement 1:1 Process Modeling 1:n Goals and Benefits Terminology m:1 Summary m:n Slide 27 Software Process Definition and Management - Chapter 1 Example Introduction Administrative A role is described with the help of Information activities (described independently of the person) Objectives Motivation documents, which are consumed or produced in the activities Software Process level of involvement in an activity Modeling and Improvement requirements for playing a role (e.g., qualifications) Process Modeling Goals and Benefits Terminology Module developer Summary Module development Module requirements Module Module design design Product flow Module Module coding code Control flow Document Activity Refinement Slide 28 Software Process Definition and Management - Chapter 1 Definition: Project Plan Introduction Administrative Project Plan := Information a specification of Objectives the necessary resources for the execution of a process Motivation Software Process definition, Modeling and the relations between these resources and processes, Improvement Process Modeling the produced products including the product flows, and Goals and Benefits restrictions of any type concerning the execution of the Terminology Summary process Slide 29  Lecture Software Process Definition and Management Chapter 2: Prescriptive Process Models Software Process Definition and Management - Chapter 2 Prescriptive versus Descriptive Modeling Prescriptive Process Models Objectives Introduction Prescriptive Process Model Classes Process Standards Process 27. Integration Test Customer Data Representation in (Host) Tools Organizations APS Deploying TSPA (from P3) 30. Customer Prescriptive Process Test Protocol Data Upgrade/ Tool- Upgrade Specification Models Summary 28. Integration Test Customer Data (Target) Data Delta Conformance Regression Test Cases Test Cases Slide 2 Software Process Definition and Management - Chapter 2 Introduction The development of computer systems became more complex Prescriptive than one person could achieve in a short time. Process Models Objectives Introduction Prescriptive Process Many methodologies have been employed to formalise the Model Classes process, ensure quality and manage the production of a Process Standards commercial product. Process Representation in Organizations In traditional system development methodologies, the Deploying Prescriptive Process requirements for the system are determined at the beginning of Models the development project and often fixed from that point on. Summary This means that the cost of changing the requirements at a later stage will be high. Agile approach of developing software appeared. Agile approach is a lot less rigorous than the traditional system development methodologies. Slide 3 Software Process Definition and Management - Chapter 2 prescriptive and descriptive process models. Prescriptive Prescriptive process models tell us how something should be Process Models Objectives done, whereas descriptive process models describe how Introduction something is done in reality. Prescriptive Process Model Classes Process Standards Whereas a descriptive process model is created by observing the Process processes actually performed, a prescriptive process model Representation in Organizations typically aims to address all relevant issues of developing a piece Deploying of software. Prescriptive Process Models Summary A descriptive process model describes what people do every day—which means that it reflects current practices. A prescriptive model tells people to do (some) things differently, which means that they need to change their behavior. Deploying a prescriptive process model means changing people’s behavior! Slide 4 Software Process Definition and Management - Chapter 2 prescriptive and descriptive process models. Prescriptive Descriptive and prescriptive models follow each other in a cycle. Process Models Objectives Introduction Prescriptive Process Model Classes Process Standards Process Representation in Organizations Deploying Prescriptive Process Models Summary Using this model, problems are identified and mitigated by changes to the process model, often using additional external knowledge such as best practices. This model then becomes a prescriptive process model, effectively instructing people to do things differently than before. Slide 5 Software Process Definition and Management - Chapter 2 Software Development Lifecycle Models and Methodologies Prescriptive Families of Software development lifecycle models Process Models Objectives Waterfall model Introduction Prescriptive Process Prototyping Model Classes Spiral model Cus tomer Requirements Process Standards Requirements s pecification Us e s pecification Incremental model Design Team I ncremental development plan Documentation Team Process I ncremental des ign Testing Team for each increment Us er/s ys tem documentation Tes t-cas e generation Correctnes s verification Representation in Correct? Statis tical tes ting No Yes Organizations Certification model I ncremental Certified? certified s ys tem No Yes Deploying Prescriptive Process Models Summary Slide 6 Software Process Definition and Management - Chapter 2 Lifecycle Models – Waterfall Model (1/3) Prescriptive System Process Models Requirements Objectives Introduction Prescriptive Process Software Requirements Model Classes Process Standards Process Analysis Representation in Organizations Deploying Program Prescriptive Process Design Models Summary Coding Testing Operations Slide 7 Software Process Definition and Management - Chapter 2 Lifecycle Models – Waterfall Model Prescriptive Advantages. Process Models Objectives ▪ Typically, waterfall-like projects face only few problems during Introduction Prescriptive Process integration. Model Classes Process Standards ▪ Version and configuration management is also simplified. Process Representation in Organizations Challenges. Deploying Prescriptive Process ▪ Unexpected requirements or context changes pose high risks. Models Summary ▪ Gaining experience and learning during a project is difficult. ▪ Fixed delivery deadlines are risky for waterfall projects. ▪ The documentation created is often voluminous and heavyweight. ▪ The waterfall approach does not scale very well for large projects and long cycle times. Slide 8 Software Process Definition and Management - Chapter 2 Iterative Enhancement: Overview Prescriptive Idea: Process Models Objectives Develop each increment (i.e., a product part that fulfills a Introduction subset of requirements) in a Waterfall style; integrate Prescriptive Process Model Classes increment by increment into the product until delivery. Process Standards The focus of the development of an increment might be on Process the completion of functionality or structure, but it can also be Representation in Organizations on refinement and improvement Deploying Strictly sequential control flow can be weakened by controlled Prescriptive Process Models iterations Summary Prerequisites: Structure of the problem permits incremental development Slide 9 Software Process Definition and Management - Chapter 2 Iterative Enhancement Model Prescriptive Process Models Objectives Introduction Prescriptive Process Model Classes Process Standards Process Representation in Organizations Deploying Prescriptive Process Models Summary Ref.: Rombach Slide 10 Software Process Definition and Management - Chapter 2 Iterative Enhancement Model Prescriptive Process Models Objectives Introduction Prescriptive Process Model Classes Process Standards Process Representation in Organizations Deploying Prescriptive Process Models Summary Ref.: Rombach Slide 11 Software Process Definition and Management - Chapter 2 Iterative Enhancement Model Prescriptive Process Models Objectives Introduction Prescriptive Process Model Classes Process Standards Process Representation in Organizations Deploying Prescriptive Process Models Summary Ref.: Rombach Slide 12 Software Process Definition and Management - Chapter 2 Iterative Enhancement Model Prescriptive Process Models Objectives Introduction Prescriptive Process Model Classes Process Standards Process Representation in Organizations Deploying Prescriptive Process Models Summary Ref.: Rombach Slide 13 Software Process Definition and Management - Chapter 2 Iterative Enhancement Model Prescriptive Advantages. Process Models Objectives Introduction Prescriptive Process Iterative projects support efficient learning. With iterations Model Classes designed properly, the core of the final product is available very Process Standards early, thus featuring essential properties of the complete product. Process Representation in This allows for early customer involvement and feedback. Organizations Iteratively developing the requirements helps when requirements Deploying Prescriptive Process are not entirely clear or still unstable. Models Integration testing is supported due to relatively small increments Summary being added at a time. In case of fixed delivery dates, incremental development helps to ensure that the most important functionality can actually be delivered—and the customer can decide what is most important to him. Slide 14 Software Process Definition and Management - Chapter 2 Iterative Enhancement Model Prescriptive Challenges. Process Models Objectives Introduction Prescriptive Process Since the product design is based on the current set of Model Classes requirements, there is a risk that requirements showing up later Process Standards may be expensive to fulfill, due to design decisions made earlier. Process Representation in Organizations Good and comprehensive version and configuration management Deploying Prescriptive Process is necessary to distinguish increments. Models Summary Integration may become increasingly difficult with the number of iterations, depending on how well requirements may be partitioned and on the system architecture. Note: Many modern software process models, such as the Unified Process, Extreme Programming, or Scrum follow an iterative pattern Slide 15 Software Process Definition and Management - Chapter 2 Lifecycle Models – Prototyping Model Prescriptive Problem Process Models Description Objectives Introduction Prescriptive Process Customer Requirements Model Classes Process Standards Process Executable Developer Representation in Requirements System Organizations Deploying Prescriptive Process Models Summary Executable Units Unit Code Note that developer requirements or even customer requirements typically directly lead to code, skipping all the other steps encountered. Slide 16 Software Process Definition and Management - Chapter 2 Lifecycle Models – Prototyping Model (1/3) Prescriptive ▪ Prototyping concentrates on the development of an executable version Process Models of the system that fulfills a limited number of requirements. Objectives Introduction Prescriptive Process ▪ Specifically, user interfaces are often simplified and/or performance and Model Classes throughput requirements are reduced or even ignored. Process Standards Process Representation in ▪ The primary goal of building prototypes is to gain initial experience. Organizations Deploying ▪ Getting a first version of the final product should usually not be a goal. Prescriptive Process Models Summary ▪ In fact, when all questions have been answered by the prototype, it should be thrown away and a system fulfilling all requirements should be developed based on one of the other lifecycle models. Slide 17 Software Process Definition and Management - Chapter 2 Lifecycle Models – Prototyping Model Prescriptive Advantages: Process Models Objectives Introduction ▪ A prototype can be developed when the final properties are not Prescriptive Process entirely clear. Model Classes Process Standards ▪ The direct contact between customer and developer reduces Process Representation in misunderstandings. Organizations Deploying ▪ Inconsistent requirements are discovered earlier, either by the Prescriptive Process Models developer or by the customer who evaluates the prototype. Summary ▪ The risk of project failure (e.g., developing a product that does not satisfy the customer requirements) is reduced due to the early involvement of the customer. Slide 18 Software Process Definition and Management - Chapter 2 Lifecycle Models – Prototyping Model Prescriptive Challenges. Process Models Objectives Introduction ▪ There is an inherent risk that side effects are not sufficiently Prescriptive Process considered, especially nonfunctional requirements such as Model Classes reliability or safety. Process Standards Process Representation in ▪ Another risk is that the customer (or the developer) considers the Organizations prototype as the first version of the system, and that the system Deploying will be evolved from the prototype, potentially leading to poorly Prescriptive Process Models documented, badly architected systems. Summary ▪ The prototyping phase of a project may also induce higher costs compared to a non-prototyped approach. Conclusion: ▪ A prototype is a great way to clarify ambiguous or unknown requirements; however, don’t ever confuse it with the first version of the actual system! Slide 19 Software Process Definition and Management - Chapter 2 Lifecycle Models – Spiral Model cumulative cost Prescriptive Progress Process Models through Objectives steps Introduction Determine objectives, Evaluate alternatives, Prescriptive Process alternatives, identify, resolve risks constraints Model Classes Process Standards Risk analysis Process Risk Representation in analysis Organizations Risk analysis Deploying R. a. Operational Prescriptive Process Prototype 2 Prototype 3 Prototype Commitment P.1 Review Models partition Requirements plan lifecycle plan Concept of Summary operation Softw are requirements Softw are Detailed product design design Development Requirements plan validation Code Unit test Integration Design validation and test plan and verification Integration and test Acceptance test Develop, verify Plan next phases Implementation next-level product Slide 20 Software Process Definition and Management - Chapter 2 Lifecycle Models – Spiral Model Prescriptive The spiral model combines aspects of the waterfall model, the iterative Process Models enhancement model, and prototyping. Objectives Introduction Prescriptive Process The first step of each spiral cycle identifies the objectives of the Model Classes product part being elaborated (e.g., performance or functionality), Process Standards Process the different alternatives for implementing the product part (e.g., Representation in different designs or reuse of existing components), and the Organizations constraints for each of the identified alternatives (e.g., cost or Deploying schedule). Prescriptive Process Models Summary The next step evaluates the identified alternatives and identifies and resolves risks that come with the different alternatives. The third step is determined by the risks that remain after the second step. During the third step, the development approach that is suited best for the risks is chosen. Finally, the next phases are planned, and the complete cycle is reviewed by the stakeholders. Slide 21 Software Process Definition and Management - Chapter 2 Lifecycle Models – Spiral Model Prescriptive Prerequisite for applying the spiral model is: Process Models Objectives Introduction ▪ the capability to identify and assess risks, as well as a project context Prescriptive Process that allows for changing the process model during project run-time. Model Classes Process Standards Process Representation in Organizations Advantages. Deploying Prescriptive Process ▪ The third step accommodates features of other lifecycle process models Models as needed. Summary ▪ The spiral model is therefore very flexible. ▪ The explicit consideration of risks avoids many of the difficulties of other process models. ▪ Similarly, unattractive alternatives are identified and eliminated early. ▪ The spiral model forms a single approach for software development and maintenance, whereas other models often concentrate on one or the other. Slide 22 Software Process Definition and Management - Chapter 2 Lifecycle Models – Spiral Model Prescriptive Challenges. Process Models Objectives ▪ For contract software, the spiral model is difficult to apply because Introduction Prescriptive Process individual project phases are not fully determined during project setup. Model Classes Process Standards ▪ It relies heavily on the organization’s expertise with respect to risk Process assessment—therefore, a bad risk assessment may lead to the Representation in Organizations selection of bad alternatives or development approaches. Deploying Prescriptive Process Models Summary Slide 23 Software Process Definition and Management - Chapter 2 Rational Unified Process (RUP) Prescriptive Process Models Objectives Phases Introduction Prescriptive Process Inception Elaboration Construction Transition Model Classes Process Standards Requirements Process one iteration in Representation in the elaboration Organizations phase Analysis Deploying Core Workflows Prescriptive Process Models Design Summary Implementation Test Iteration Iteration Iteration Iteration … 1 2 n-1 n Slide 24 Software Process Definition and Management - Chapter 2 Rational Unified Process (RUP) Prescriptive Process Models Unified Process is a generic process framework for software Objectives development. Introduction Prescriptive Process Model Classes It consists of a generic description of phases and activities that Process Standards can—and normally must!—be adapted for different types of Process organizations, the class of software system to be developed, Representation in different application domains, competence levels, and project sizes. Organizations Deploying Prescriptive Process The Unified Process distinguishes project phases like the waterfall model Models does and supports iterative development within the phases like the Summary iterative enhancement model does. It also specifically considers risks during the iterations, borrowing from the spiral model. In addition, it contains traces of the prototyping model, since it recommends building prototypes within iterations under special circumstances. Slide 25 Software Process Definition and Management - Chapter 2 Rational Unified Process (RUP) Prescriptive Process Models Objectives The Unified Process is component based, i.e., the system to be built is Introduction compiled from software components that are interconnected via well- Prescriptive Process defined interfaces. Model Classes Process Standards Process The Unified Modeling Language (UML) is used to model all central Representation in artifacts describing the system—e.g., requirements and design. Both Organizations UML and the Unified Process were developed in parallel. Deploying Prescriptive Process Models The Unified Process is use-case driven. Within the Unified Process, use Summary cases replace the traditional functional specification of the system. The Unified Process is also architecture-centric, i.e., it focuses strongly on the system architecture, embodying the most significant static and dynamic aspects of the system. The Unified Process is iterative and incremental. Slide 26 Software Process Definition and Management - Chapter 2 Rational Unified Process (RUP) Prescriptive Process Models Objectives Introduction Prescriptive Process Model Classes Process Standards Process Representation in Organizations Deploying Prescriptive Process Models Summary Phases of RUP 1.Inception 2.Elaboration 3.Construction 4.Transition 5.Production Slide 27 Software Process Definition and Management - Chapter 2 Rational Unified Process (RUP) Prescriptive Process Models 1.Inception Objectives Introduction Prescriptive Process 1. Communication and planning are the main ones. Model Classes Process Standards 2. Identifies the scope of the project using a use-case Process model allowing managers to estimate costs and time Representation in required. 3. Customers’ requirements are identified and then it Organizations Deploying Prescriptive Process becomes easy to make a plan for the project. Models Summary 4. The project plan, Project goal, risks, use-case model, and Project description, are made. 5. The project is checked against the milestone criteria and if it couldn’t pass these criteria then the project can be either canceled or redesigned. Slide 28 Software Process Definition and Management - Chapter 2 Rational Unified Process (RUP) Prescriptive Process Models Objectives Introduction 2.Elaboration Prescriptive Process Model Classes Process Standards 2. Planning and modeling are the main ones. Process 3. A detailed evaluation and development plan is carried out and diminishes the risks. Representation in Organizations Deploying 4. Revise or redefine the use-case model (approx. Prescriptive Process Models 80%), business case, and risks. Summary 5. Again, checked against milestone criteria and if it couldn’t pass these criteria then again project can be canceled or redesigned. 6. Executable architecture baseline. Slide 29 Software Process Definition and Management - Chapter 2 Rational Unified Process (RUP) Prescriptive 3.Construction Process Models Objectives Introduction 3. The project is developed and completed. Prescriptive Process Model Classes 4. System or source code is created and then testing Process Standards is done. Process 5. Coding takes place. Representation in Organizations Deploying 4.Transition Prescriptive Process Models Summary 4. The final project is released to the public. 5. Transit the project from development into production. 6. Update project documentation. 7. Beta testing is conducted. 8. Defects are removed from the project based on feedback from the public. Slide 30 Software Process Definition and Management - Chapter 2 Rational Unified Process (RUP) Prescriptive Process Models Production Objectives Introduction Prescriptive Process The final phase of the model. Model Classes The project is maintained and updated Process Standards Process accordingly. Representation in Organizations Deploying Prescriptive Process Models Summary Slide 31 Software Process Definition and Management - Chapter 2 Rational Unified Process (RUP) Advantages of Rational Unified Process (RUP) Prescriptive Process Models Objectives Introduction Prescriptive Process 1.RUP provides good documentation, it completes the Model Classes process in itself. Process Standards 2.RUP provides risk-management support. Process Representation in 3.RUP reuses the components, and hence total time duration Organizations is less. 4.Good online support is available in the form of tutorials Deploying Prescriptive Process Models and training. Summary Disadvantages of Rational Unified Process (RUP) 1.Team of expert professional is required, as the process is complex. 2.Complex and not properly organized process. 3.More dependency on risk management. 4.Hard to integrate again and again. Slide 32 Software Process Definition and Management - Chapter 2 Agility in Software Development Prescriptive Process Models Agility in software development is not a methodology; it is an Objectives approach. Introduction A number of different Agile methodologies have been developed Prescriptive Process Model Classes that have embraced the Agile approach, such as: Process Standards Extreme Programming (XP), Dynamic Systems Development Process Representation in Method, Feature-Driven Design, Crystal, Agile Modelling and Organizations SCRUM. Deploying Agile principles (Beck et al., 2001): Prescriptive Process Models 1. Welcome changing requirements. Summary 2. The highest priority is to satisfy the customer through early and continuous delivery of valuable software. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Working software is the primary measure of progress. Slide 33 Software Process Definition and Management - Chapter 2 Extreme Programming (XP): Overview Prescriptive Process Models Like other agile methodologies, XP differs from traditional Objectives methodologies mainly in placing a higher value on adaptability Introduction than on predictability. Prescriptive Process Model Classes Adapt to changing requirements at any point during the project life Process Standards instead of defining all requirements at the beginning of a project. Process Representation in XP uses Agile principles. Organizations XP lowers the cost of change. Deploying Prescriptive Process XP helps to achieve a high degree of customer satisfaction Models because customers notice that it creates a working software Summary faster, and that software tends to have very few defects. Slide 34 Software Process Definition and Management - Chapter 2 Extreme Programming (XP): Overview Prescriptive Process Models Objectives Introduction Extreme Programming improves a software project in five Prescriptive Process essential ways: Model Classes communication, simplicity, feedback, respect, and Process Standards Process courage. Representation in Extreme Programmers constantly communicate with their Organizations Deploying customers and fellow programmers. Prescriptive Process They keep their design simple and clean. Models They get feedback by testing their software starting on Summary day one. They deliver the system to the customers as early as possible and implement changes as suggested. Every small success deepens their respect for the unique contributions of each and every team member. With this foundation Extreme Programmers are able to courageously respond to changing requirements and technology. Slide 35 Software Process Definition and Management - Chapter 2 Extreme Programming: Overview Prescriptive Process Models Planning Objectives Introduction Collect user stories Prescriptive Process Create prototype architecture Model Classes Create release plan Process Standards Develop test scenarios Process Representation in Organizations Deploying Prescriptive Process Develop Increment Models Develop test cases Summary Plan & implement the increment Revise architecture Test current increment Collect data Iteration 1 Iteration 2 … Perform Acceptance Test (Ref: Bunse / von Knethen: Vorgehensmodelle kompakt) Slide 36 Software Process Definition and Management - Chapter 2 Extreme Programming: Planning Prescriptive Process Models Objectives Planning Introduction Prescriptive Process Collect user stories Model Classes Process Standards → Text documents Process → Use cases Create release plan Representation in → Increment planning Organizations → Day tasks Deploying → Data recording Prescriptive Process Create prototype architecture Models Summary → Class diagrams Develop test scenarios → Scenarios (Ref: Bunse / von Knethen: Vorgehensmodelle kompakt) Slide 37 Software Process Definition and Management - Chapter 2 Extreme Programming: Iterative Phase Prescriptive Process Models Objectives Develop test cases Introduction → Test cases Prescriptive Process → Test environment Model Classes Process Standards Process Representation in Revise architecture Plan & implement the increment Organizations → Class diagram Deploying → Source code Prescriptive Process Models Summary Collect data Test current increment →Measurement data → Test results Iteration 1 Iteration 2 … Perform Acceptance Test → Test results (Ref: Bunse / von Knethen: Vorgehensmodelle kompakt) Slide 38 Software Process Definition and Management - Chapter 2 What is Scrum? Prescriptive Agile Management Framework for SW development projects Process Models Objectives Introduction Prescriptive Process Model Classes Process Standards Process Representation in Organizations Deploying Prescriptive Process Models Summary Slide 39 Software Process Definition and Man