Chapter 2 Process Models Software Engineering A Practitioners

Chapter 2 Process Models Software Engineering: A Practitioner’s Approach, 7/e by Roger S. Pressman

Software Engineering The IEEE definition • The application of systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; • that is, the application of engineering to software. 2

A Layered Technology tools methods process model a “quality” focus SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2 3

A Layered Technology (cont. ) “We think that software developers are missing a vital truth: most organizations don’t know what they do. They think they know, but they don’t know. ” Tom De. Marco Are All developers good? 4

A Layered Technology (cont. ) • Quality – Any engineering approach must rest on organizational commitment to quality and to assure a continuous process improvement culture. • Process – Defines as a collection of work activities, actions, and tasks that are performed when some work product is to be created. – Defines who is doing what, when, and how to reach a certain goal. – Forms the basis for management control of software projects. • Methods – technical “how to” for building software – Broad array of tasks: communication, requirements analysis, design modeling, program construction, testing, and support • Tools – Automated support for process and methods 5

A Process Framework Software Process framework Umbrella Activities Framework activity 1 Process framework Framework activities work tasks work products milestones & deliverables checkpoints Framework activity n Umbrella Activities 6

Five Activities of a Generic Process framework 1. Communication 2. Planning 3. Modeling – Analysis of requirements – Design 4. Construction – Code generation – Testing 5. Deployment – Delivery – Feedback 7

Five Activities of a Generic Process framework (cont. ) • Communication: communicate with customer to understand objectives and gather requirements • Planning: • Modeling: • Construction: • Deployment: SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2 8

Five Activities of a Generic Process framework (cont. ) • Communication: • Planning: creates a “map” map that defines the work by describing tasks, risks and resources, work products and work schedule. • Modeling: • Construction: • Deployment: SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2 9

Five Activities of a Generic Process framework (cont. ) • Communication: • Planning: • Modeling: Create a “sketch”, sketch what it looks like architecturally, how the essential parts fit together and other characteristics. • Construction: • Deployment: SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2 10

Five Activities of a Generic Process framework (cont. ) • Communication: • Planning: • Modeling: • Construction: code generation and the testing. • Deployment: SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2 11

Five Activities of a Generic Process framework (cont. ) • Communication: • Planning: • Modeling: • Construction: • Deployment: Delivered to the customer who evaluates the products & provides feedback based on the evaluation. SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2 12

Five Activities of a Generic Process framework (cont. ) • These five framework activities can be used to all software development, regardless of the application domain, size of the project, complexity of the efforts etc. – though the details will be different in each case. • For many software projects, these framework activities are applied iteratively as a project progresses. Each iteration produces a software increment that provides a subset of overall software features and functionality. SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2 13

Umbrella Activities • Complete the five process framework activities and help team manage and control progress, quality, change, and risk. – – – – Software project tracking and control: Risk management: Software quality assurance: Technical reviews: Measurement: Software configuration management: Reusability management: Work product preparation and production: SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2 14

Umbrella Activities • Software project tracking & control: assess progress against the plan and take actions to maintain the schedule. • Risk management: • Software quality assurance: • Technical reviews: • Measurement: • Software configuration management: • Reusability management: • Work product preparation and production: SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2 15

Umbrella Activities • • Software project tracking & control: Risk management: assesses risks that may affect the outcome and quality. Software quality assurance: Technical reviews: • Measurement: • Software configuration management: • Reusability management: • Work product preparation and production: SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2 16

Umbrella Activities • • Software project tracking & control: Risk management: Software quality assurance: defines and conduct activities to ensure quality. Technical reviews: • Measurement: • Software configuration management: • Reusability management: • Work product preparation and production: SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2 17

Umbrella Activities • • Software project tracking & control: Risk management: Software quality assurance: Technical reviews: assesses work products to uncover and remove errors before going to the next activity. • Measurement: • Software configuration management: • Reusability management: • Work product preparation and production: SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2 18

Umbrella Activities • • Software project tracking & control: Risk management: Software quality assurance: Technical reviews: • Measurement: define and collects process, project, and product measures to ensure stakeholder’s needs are met. • Software configuration management: • Reusability management: • Work product preparation and production: SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2 19

Umbrella Activities • • Software project tracking & control: Risk management: Software quality assurance: Technical reviews: • Measurement: • Software configuration management: manage the effects of change throughout the software process. • Reusability management: • Work product preparation and production: SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2 20

Umbrella Activities • • Software project tracking & control: Risk management: Software quality assurance: Technical reviews: • Measurement: • Software configuration management: • Reusability management: defines criteria for work product reuse and establishes mechanism to achieve reusable components. • Work product preparation and production: SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2 21

Umbrella Activities • • Software project tracking & control: Risk management: Software quality assurance: Technical reviews: • Measurement: • Software configuration management: • Reusability management: • Work product preparation and production: create work products such as models, documents, logs, forms and lists. SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2 22

Process Flow These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e 23 (Mc. Graw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

Process Patterns • A Process Pattern – describes a process-related problem that is encountered during software engineering work, – identifies the environment in which the problem has been encountered, – suggests one or more proven solutions to the problem. 24

Process Pattern Types 1. Stage patterns 2. Task patterns 3. Phase patterns 25

Process Pattern Types 1. Stage patterns—defines a problem associated with a framework activity for the process. 2. Task patterns 3. Phase patterns 26

Process Pattern Types 1. Stage patterns 2. Task patterns—defines a problem associated with a software engineering action or work task and relevant to successful software engineering practice 3. Phase patterns 27

Process Pattern Types 1. Stage patterns 2. Task patterns 3. Phase patterns—define the sequence of framework activities that occur with the process, even when the overall flow of activities is iterative in nature. 28

Prescriptive Process Models • Traditional process models • Specialized process models • Unified process (Source: Pressman, R. Software Engineering: A Practitioner’s Approach. Mc. Graw-Hill, 2005)

Traditional Process Models • Defines a distinct set of activities, actions, tasks, milestones, and work products that are required to engineer high-quality software • The activities can be – linear, – incremental, – evolutionary

Waterfall Model (Diagram) Communication Project initiation Requirements gathering Planning Estimating Scheduling Tracking Modeling Analysis Design Construction Code Test Deployment Delivery Support Feedback 31

Waterfall Model (Description) Description • Oldest software lifecycle model & best understood by upper management • Used when requirements are well understood and risk is low • Work flow is in a linear fashion (i. e. , sequential) • Used often with well-defined adaptations or enhancements to current software 32

Waterfall Model (Problems) Problems • Doesn't support iteration, so changes can cause confusion • Difficult for customers to state all requirements explicitly and up front • Requires customer patience because a working version of the program doesn't occur until the final phase 33

Incremental Model (Diagram) Diagram Increment #1 Communication Planning Modeling Construction Deployment Increment #2 Communication Planning Modeling Construction Deployment Increment #3 Communication Planning Modeling Construction Deployment 34

Incremental Model (Description) Description • Used when requirements are well understood • Multiple independent deliveries are identified • Work flow is in a linear (i. e. , sequential) fashion within an increment and is staggered between increments • Iterative in nature; focuses on an operational product with each increment • Provides a needed set of functionality sooner while delivering optional components later • Useful also when staffing is too short for a full-scale development 35

Prototyping Model (Diagram) Diagram Quick Planning Start Communication Modeling Quick Design Deployment, Delivery, and Feedback Construction Of Prototype 36

Prototyping Model (Description) Description Follows an evolutionary and iterative approach Used when requirements are not well understood Serves as a mechanism for identifying software requirements Focuses on those aspects of the software that are visible to the customer/user • Feedback is used to refine the prototype • • 37

Prototyping Model (Potential Problems) Problems • The customer sees a "working version" of the software, wants to stop all development and then buy the prototype after a "few fixes" are made • Developers often make implementation compromises to get the software running quickly – (e. g. , language choice, user interface, operating system choice, inefficient algorithms) 38

Spiral Model (Diagram) Diagram Planning Communication Modeling Start Deployment Construction 39

Spiral Model (Description) Description • Follows an evolutionary approach • Used when requirements are not well understood and risks are high • Inner spirals focus on identifying software requirements and project risks; may also incorporate prototyping • Outer spirals take on a classical waterfall approach after requirements have been defined, but permit iterative growth of the software • Operates as a risk-driven model…a go/no-go decision occurs after each complete spiral in order to react to risk determinations • Requires considerable expertise in risk assessment • Serves as a realistic model for large-scale software development 40

General Weaknesses of Evolutionary Process Models 1) Prototyping poses a problem to project planning because of the uncertain number of iterations required to construct the product 2) Evolutionary software processes do not establish the maximum speed of the evolution • If too fast, the process will fall into chaos • If too slow, productivity could be affected 3) Software processes should focus first on flexibility and extensibility, and second on high quality • We should prioritize the speed of the development over zero defects • Extending the development in order to reach higher quality could result in late delivery 41

Specialized Process Models

Component-based Development Model • Consists of the following process steps – Available component-based products are researched and evaluated for the application domain in question – Component integration issues are considered – A software architecture is designed to accommodate the components – Components are integrated into the architecture – Comprehensive testing is conducted to ensure proper functionality • Relies on a robust component library • Capitalizes on software reuse, which leads to documented savings in project cost and time 43

Formal Methods Model (Description) Description • Encompasses a set of activities that leads to formal mathematical specification of computer software • Enables a software engineer to specify, develop, and verify a computer-based system by applying a rigorous, mathematical notation • Ambiguity, incompleteness, and inconsistency can be discovered and corrected more easily through mathematical analysis • Offers the promise of defect-free software • Used often when building safety-critical systems 44

Formal Methods Model (Challenges) Challenges • Development of formal methods is currently quite timeconsuming and expensive • Because few software developers have the necessary background to apply formal methods, extensive training is required • It is difficult to use the models as a communication mechanism for technically unsophisticated customers 45

The Unified Process

Background • They eventually worked together on a unified method, called the Unified Modelling Language (UML) – UML is a robust notation for the modelling and development of objectoriented systems – UML became an industry standard in 1997 – However, UML does not provide the process framework, only the necessary technology for object-oriented development • Unified process developed which is a framework for object-oriented software engineering using UML – Draws on the best features and characteristics of conventional software process models – Emphasizes the important role of software architecture – Consists of a process flow that is iterative and incremental, thereby providing an evolutionary feel 47

Background (continued) continued • Consists of 5 phases: 1. 2. 3. 4. 5. inception, elaboration, construction, transition, production 48

Phases of the Unified Process Elaboration Inception planning communication modeling construction Construction deployment Production Transition 49

(1) - Inception Phase • Encompasses both customer communication and planning activities of the generic process • Business requirements for the software identified • A rough architecture for the system is proposed • A plan is created for an incremental, iterative development • Fundamental business requirements are described through preliminary use cases – A use case describes a sequence of actions that are performed by a user 50

(2) - Elaboration Phase • Encompasses both the planning and modelling activities of the generic process • Refines and expands the preliminary use cases • Expands the architectural representation to include five views – – – Use-case model Analysis model Design model Implementation model Deployment model • Often results in an executable architectural baseline that represents a first cut executable system • The baseline demonstrates the viability of the architecture but does not provide all features and functions required to use the system 51

(3) - Construction Phase • Encompasses the construction activity of the generic process • Uses the architectural model from the elaboration phase as input • Develops or acquires the software components that make each use-case operational • Analysis and design models from the previous phase are completed to reflect the final version of the increment • Use cases are used to derive a set of acceptance tests that are executed prior to the next phase 52

(4) - Transition Phase • Encompasses the last part of the construction activity and the first part of the deployment activity of the generic process • Software is given to end users for beta testing and user feedback reports on defects and necessary changes • The software teams create necessary support documentation (user manuals, trouble-shooting guides, installation procedures) • At the conclusion of this phase, the software increment becomes a usable software release 53

(5) - Production Phase • Encompasses the last part of the deployment activity of the generic process • On-going use of the software is monitored • Support for the operating environment (infrastructure) is provided • Defect reports and requests for changes are submitted and evaluated 54

Unified Process Work Products • Work products are produced in each of the first four phases of the unified process • In this course, we will concentrate on the analysis model and the design model work products • Analysis model includes – Scenario-based model, class-based model, and behavioural model • Design model includes – Component-level design, interface design, architectural design, and data/class design 55

Agile Process Models SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2 56

Agile Process Models –The prescriptive process models stress detailed definition, identification, and application of process activates and tasks. Intent is to improve system quality, make projects more manageable, make delivery dates and costs more predictable, and guide teams of software engineers as they perform the work required to build a system. –Unfortunately, there have been times when these objectives were not achieved. If prescriptive models are applied strictly and without adaptation, they can increase the level of organization. –Agile process models emphasize project “agility (alertness)” and follow a set of principles that lead to a more informal approach to software process. It emphasizes maneuverability and adaptability It is particularly useful when Web applications are engineered. SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2 57

The Essence of Practice • How does the practice of software engineering fit in the process activities mentioned above? Namely, – communication, – planning, – modeling, – construction – deployment. • the essence of problem solving is outlined in 4 points: 1. Understand the problem (communication and analysis). 2. Plan a solution (modeling and software design). 3. Carry out the plan (code generation). 4. Examine the result for accuracy (testing and quality assurance). SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2 58

Understand the Problem • Who has a stake in the solution to the problem? That is, who are the stakeholders? • What are the unknowns? What data, functions, and features are required to properly solve the problem? • Can the problem be classified? Is it possible to represent smaller problems that may be easier to understand? • Can the problem be represented graphically? Can an analysis model be created? SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2 59

Plan the Solution • Have you seen similar problems before? Are there patterns that are recognizable in a potential solution? Is there existing software that implements the data, functions, and features that are required? • Has a similar problem been solved? If so, are elements of the solution reusable? • Can sub-problems be defined? If so, are solutions readily apparent for the sub-problems? • Can you represent a solution in a manner that leads to effective implementation? Can a design model be created? SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2 60

Carry Out the Plan • Does the solutions conform to the plan? Is source code traceable to the design model? • Is each component part of the solution provably correct? Has the design and code been reviewed, or better, have correctness proofs been applied to algorithm? SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2 61

Examine the Result • Is it possible to test each component part of the solution? Has a reasonable testing strategy been implemented? • Does the solution produce results that conform to the data, functions, and features that are required? Has the software been validated against all stakeholder requirements? SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2 62

Software Myths Examples • Myth 1: Once we write the program and get it to work, our job is done. • Reality: the sooner you begin writing code, the longer it will take you to get done. 60% to 80% of all efforts are spent after software is delivered to the customer for the first time. • Myth 2: Until I get the program running, I have no way of assessing its quality. • Reality: technical review are a quality filter that can be used to find certain classes of software defects from the inception of a project. • Myth 3: software engineering will make us create voluminous and unnecessary documentation and will invariably slow us down. • Reality: it is not about creating documents. It is about creating a quality product. Better quality leads to a reduced rework. Reduced work results in faster delivery times. • Many people recognize the fallacy of the myths. Regrettably, habitual attitudes and methods foster poor management and technical practices, even when reality dictates a better approach. SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2 63

End Thank you SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2 64