Software Engineering: A Practitioner’s Approach, 6/e Chapter 2, 3, &4 Process copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited.

Software Process A framework for the tasks that are required to build high-quality software. A process defines who is doing what, when, and how to reach a certain goal.

A Process Framework Process framework Umbrella Activities Framework activity #1 work tasks work products milestones & deliverables QA checkpoints … Framework activity #n Umbrella Activities

Generic Framework Activities Communication: Communication and collaboration with the stakeholders and encompasses requirement gathering and other activities. Planning: Establishment of a plan: the technical tasks, risks, resources, work products, and a work schedule Modeling: Analysis of requirements: better understanding of requirements Design: that achieves the requirements Construction Code generation: manual or automated Testing: uncover errors. Deployment: Delivery of software for customer evaluation with feedback.

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

The Process Model: Adaptability The framework activities will always be applied on every project ... BUT The tasks (and degree of rigor) for each activity will vary based on: the type of project characteristics of the project common sense judgment; concurrence of the project team

Process Patterns Process patterns define a set of activities, actions, work tasks, work products and/or related behaviors A template is used to define a pattern Typical examples: Customer communication (a process activity) Analysis (an action) Requirements gathering (a process task) Reviewing a work product (a process task) Design model (a work product) http://www.ambysoft.com/processPatternsPage.html

Process Patterns – An Example Pattern Name: Prototyping Intent: The objective is to build a model that can be assessed iteratively by stakeholders in an effort to identify or solidify sw requirements Type: Phase pattern Initial Context: The following preconditions must be met: 1. stakeholders have been identified; 2. a mode of communication b/w stakeholders and sw team has been established; 3. the overriding problem has been identified by stakeholders; 4. an initial understanding of proj. scope, basic requirements, and constraints has been developed. Problem: Requirements are hazy or nonexistent. Stakeholders are unsure that they need. Solution: A description of the prototyping process is presented. Resulting Context: A software prototype that identifies basic requirements is approved by stakeholders. Related Patterns: customer-communications; iterative design, … Known Uses/Examples: Prototyping is recommended when requirements are uncertain.

The Primary Goal of Any Software Process: High Quality Remember: High quality = project timeliness Why? Less rework!

Two Schools of Process Models Prescriptive process models advocate an orderly approach to software engineering Agile development Encourages early incremental delivery of software Stresses continuous communication between developers and customers

Prescriptive Process Models Define a distinct set of activities, actions, tasks, milestones, and work products. Software engineers and managers adapt a prescriptive process model to their need Guide a software team through a set of framework activities that organized into a linear, incremental, or evolutionary process flow The work products are the programs, documents, and data that are produced as a consequence of the activities.

The Waterfall Model

The Waterfall Model It suggests a systematic, sequential approach to software development. The oldest paradigm for software engineering Suitable for systems whose requirements are well-defined and reasonably stable. Drawbacks: Real projects rarely follow the sequential flow. It is often hard for the customer to state all requirements explicitly. A working product will not be available until late in the project time-span. Requirement errors may not be found until they are very costly to fix.

The Incremental Model

The Incremental Model The waterfall model applied in an iterative fashion. Each linear sequence produces deliverable increments of the software. Normally core product is first delivered and supplementary features are incrementally added. Useful when staffing is unavailable for a complete implementation by the project deadline. Increments may be planned to manage technical risks

Rapid Application Development

The RAD Model The incremental model with a short development cycle. Multiple RAD teams develop different components of the system in parallel. Short system development cycle is achieved by using a component-based construction approach. Suitable for systems that can be modularized in a way that enables each major function to be completed in a short period of time. Drawbacks: For large systems, it requires sufficient people to form the RAD teams If developers and customers are not committed to the rapid-fire activities, the project would fail If the system cannot modularized properly, it can be problematic. It may be difficult to achieve high performance. It may not be appropriate if technical risks are high.

Evolutionary Models: Prototyping Quick plan communication Modeling Quick design Deployment delivery & feedback Construction of prototype

Evolutionary Models: Prototyping Assists the software developer and the customer to better understand what is to be built when requirements are fuzzy. "I know this is what I asked for, but it isn't really what I wanted." A quick throwaway prototype for users to experiment and the developer to understand and refine requirements based on users’ feedback.. The customer may falsely perceive the prototype as a working system, unwilling to continue for a complete system. Assumptions and design architecture of the prototype may influence implicitly the architecture of the real system. Rarely employed for complete development cycle.

Evolutionary Models: The Spiral

Evolutionary Models: The Spiral Risk-driven process model. A cyclic approach for incrementally growing a system’s degree of definition and implementation. A set of anchor point milestones for ensuring stakeholder commitment for feasible and mutually satisfactory solutions. Prototyping can be employed as a risk reduction mechanism at any stage A good approach for large-scale systems.

Still Other Process Models Component based development—systems are built by integrating Commercial off-the-shelf (COTS) software components. Following the following steps: Research and evaluate component-based products Resolve component integration issues A software architecture is designed to accommodate the components Components are integrated into the architecture Comprehensive testing is conducted. Formal methods—emphasizes the mathematical specification of requirements

Still Other Process Models Aspect-oriented software development (AOSD) Certain concerns span the whole system architecture High-level properties of the system: security, fault tolerance Application of business rules Systemic: task synchronization or memory management AOSD is a process and methodological approach for defining, specifying, designing, and constructing aspects. Unified Process—a “use-case driven, architecture-centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML) – Details coming soon

The Unified Process (UP) inception elaboration inception

UP Phases

UP Work Products

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

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

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

Extreme Programming (XP) The most widely used agile process, originally proposed by Kent Beck XP Planning Begins with the creation of “user stories” Agile team assesses each story and assigns a cost Stories are grouped to for a deliverable increment A commitment is made on delivery date After the first increment “project velocity” is used to help define subsequent delivery dates for other increments

Extreme Programming (XP) XP Design Follows the KIS principle (nothing less, nothing more.) Encourage the use of CRC cards for classes relevant to the current increment. For difficult design problems, suggests the creation of “spike solutions”—a design prototype Encourages “refactoring”—an iterative refinement of the internal program design XP Coding Recommends the construction of a unit test for the stories before coding commences Encourages “pair programming” XP Testing All unit tests are executed daily “Acceptance tests” are defined by the customer and executed to assess customer visible functionality

Extreme Programming (XP)

Adaptive Software Development Originally proposed for complex systems by Jim Highsmith ASD — distinguishing features Mission-driven planning Component-based focus Uses “time-boxing” (See Chapter 24) Explicit consideration of risks Emphasizes collaboration for requirements gathering Emphasizes “learning” throughout the process

Adaptive Software Development Speculation Adaptive cycle planning uses initiation information to define the set of release cycles (increments) Collaboration Team members multiply their talent and creative output with mutual trust. (1) criticize without animosity (2) assist without resentment (3) work as hard/harder as others Learning As development progresses members learn toward the complete cycle through focus groups, formal technical review, and postmortems.

Adaptive Software Development

Dynamic Systems Development Method Promoted by the DSDM Consortium (www.dsdm.org) DSDM—distinguishing features Similar in most respects to XP and/or ASD Nine guiding principles Active user involvement is imperative. DSDM teams must be empowered to make decisions. The focus is on frequent delivery of products. Fitness for business purpose is the essential criterion for acceptance of deliverables. Iterative and incremental development is necessary to converge on an accurate business solution. All changes during development are reversible. Requirements are baselined at a high level Testing is integrated throughout the life-cycle.

Scrum Originally proposed by Schwaber and Beedle Scrum—distinguishing features Development work is partitioned into “packets” Testing and documentation are on-going as the product is constructed Work occurs in “sprints” and is derived from a “backlog” of existing requirements Meetings are very short and sometimes conducted without chairs “demos” are delivered to the customer with the time-box allocated

Crystal Proposed by Cockburn and Highsmith Crystal—distinguishing features Actually a family of process models that allow “maneuverability” based on problem characteristics Face-to-face communication is emphasized Suggests the use of “reflection workshops” to review the work habits of the team

Feature Driven Development Originally proposed by Peter Coad et al FDD—distinguishing features Emphasis is on defining “features” a feature “is a client-valued function that can be implemented in two weeks or less.” Uses a feature template <action> the <result> <by | for | of | to> a(n) <object> Add the product to a shopping cart Display the technical spec of a product Store the shipping info for a customer A features list is created and “plan by feature” is conducted Design and construction merge in FDD