CS 455 Quiz 1 CH 1-5, User Story

Environment management.

Coordinates a process infrastructure that includes standards, tools, and other support technology available to the team.

Little's law

Cycle time = work in process/ throughput

Measurement

defines and collects process, project, and product measures that assist the team in delivering software that meets stakeholders' needs; can be used in conjunction with all other framework and umbrella activities.

Software quality assurance—

defines and conducts the activities required to ensure software quality.

Reusability management—

defines criteria for work product reuse (including software components) and establishes mechanisms to achieve reusable components.

Spike

another invention of XP, are a special type of story that is used to drive out risk and uncertainty in a user story or other project facet. Spikes may be used for a number of reasons: 1. The team may not have knowledge of a new domain, and spikes may be used for basic research to familiarize the team with a new technology or domain. 2. The story may be too big to be estimated appropriately, and the team may use a spike to analyze the implied behavior, so they can split the story into estimable pieces. 3. The story may contain significant technical risk, and the team may have to do some research or prototyping to gain confidence in a technological approach that will allow them to commit the user story to some future timebox. 4. The story may contain significant functional risk, in that while the intent of the story may be understood, it's not clear how the system needs to interact with the user to achieve the benefit implied.

Scrum principles

are consistent with the agile manifesto and are used to guide development activities within a process that incorporates the following frame- work activities: requirements, analysis, design, evolution, and delivery.

Scrum meetings—

are short (typically 15-minute) meetings held daily by the Scrum team. Three key questions are asked and answered by all team members. - What did you do since the last team meeting? - What obstacles are you encountering? - What do you plan to accomplish by the next team meeting?

Prescriptive process models

are sometimes referred to as "traditional" process mode

Technical reviews—

assess software engineering work products in an effort to uncover and remove errors before they are propagated to the next activity.

Risk management—

assesses risks that may affect the outcome of the project or the quality of the product.

Sprint

- Consist of work units that are required to achieve a requirement defined in the backlog that must be fit into a predefined time-box10 (typically 30 days). Changes (e.g., backlog work items) are not introduced during the sprint. Hence, the sprint allows team members to work in a short-term, but stable environment. - Within each framework activity, work tasks occur within a process pattern

Key Points CH 3

- Different Projects demand different task sets. The software team chooses the task set based on the problem and project characteristics. - A pattern template provides a consistent means for describing a pattern. - Assessment attempts to understand the current state of the software process with the intent of improving it.

XP Design

- Follows the KIS PRINCIPLE - Encourage the use of CRC cards - For difficult design problems, suggests the creation of "SPIKE SOLUTIONS"—a design prototype - Encourages "REFACTORING"—an iterative refinement of the internal program design

Agility

- It encourages team structures and attitudes that make communication (among team members, between technologists and business people, between software engineers and their managers) more facile. It emphasizes rapid delivery of operational software and deemphasizes the importance of intermediate work products (not always a good thing); it adopts the customer as a part of the development team and works to eliminate the "us and them" attitude that continues to pervade many software projects; it recognizes that planning in an uncertain world has its limits and that a project plan must be flexible. - ability to move quickly and easily

XP Testing

- The unit tests that are created should be implemented using a frame- work that enables them to be automated (hence, they can be executed easily and repeatedly). As the individual unit tests are organized into a "universal testing suite", integration and validation testing of the system can occur on a daily basis. This provides the XP team with a continual indication of progress and also can raise warning flags early if things go awry. - XP acceptance tests, also called customer tests, are specified by the customer and focus on overall system features and functionality that are visible and re- viewable by the customer. Acceptance tests are derived from user stories that have been implemented as part of a software release.

agile modeling (AM)

- a practice-based methodology for effective modeling and documentation of software-based systems. - Although AM suggests a wide array of "core" and "supplementary" modeling principles, those that make AM unique are: - Model with a purpose. - Use multiple models. - Travel light. - Content is more important than representation. - Know the models and the tools you use to create them. - Adapt locally.

Incremental Process Model

- combines linear and parallel process flows - linear sequences in a staggered fashion - each sequence produces deliverable "increments" (first increment is the "core product")

Evolutionary Process Models

- iterative - develop increasingly more complete software versions - prototyping and spiral flavors

Story Modeling with Index Cards

- n Cards may be arranged by feature (or epic or theme) and may be written on the same colored cards as the feature for visual differentiation. - n Cards can also be arranged by size to help developers 'see' the size relationships between different stories. - n Cards can be arranged by time or iteration to help evaluate dependencies, understand logical sequencing, see the impact on team velocity, and better align and communicate differing stakeholder priorities.

Any agile software process is characterized in a manner that addresses a number of key assumptions about the majority of software projects:

1. It is difficult to predict in advance which software requirements will persist and which will change. It is equally difficult to predict how customer priorities will change as the project proceeds. 2. For many types of software, design and construction are interleaved. That is, both activities should be performed in tandem so that design models are proven as they are created. It is difficult to predict how much design is necessary before construction is used to prove the design. 3. Analysis, design, construction, and testing are not as predictable (from a planning point of view) as we might like.

12 Agility Principles

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 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. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity—the art of maximizing the amount of work not done—is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Four broad categories of software are evolving to dominate the industry. And yet, these categories were in their infancy little more than a decade ago.

1. WebApps 2. Mobile Applications 3. Cloud Computing 4. Product line Software

Ten common patterns to split a user story

1. Workflow Steps 2. Business Rule Variations 3. Major Effort 4. Simple/Complex 5. Variations in Data 6. Data Entry Methods 7. Defer System Qualities 8. Operations (example: Create Read Update Delete (CRUD)) 9. Use Case Scenarios 10. Break Out a Spike

Anchor point milestones

A combinations of work products and conditions that are attained along the path of the spiral - are noted for each evolutionary pass. Is a realistic approach to the development of large-scale systems and software.

Model with a purpose.

A developer who uses AM should have a specific goal (e.g., to communicate information to the customer or to help better understand some aspect of the software) in mind before creating the model. Once the goal for the model is identified, the type of notation to be used and level of detail required will be more obvious.

Negotiable

A placeholder for requirements to be discussed, developed, tested, and accepted.Allows for discovery through collaboration and feedback

Unified Process (UP)

A systems development life cycle based on object-oriented techniques; follows a series of repeated steps

XP Coding

After stories are developed and preliminary design work is done, the team does not move to code, but rather develops a series of unit tests that will exercise each of the stories that is to be included in the current release (software increment).5 Once the unit test6 has been created, the developer is better able to focus on what must be implemented to pass the test. Once the code is complete, it can be unit-tested immediately, thereby providing instantaneous feedback to the developers. Encourages "pair programming" - This provides a mechanism for real-time problem solving (two heads are often better than one) and real-time quality assurance (the code is reviewed as it is created).

Retrospectives.

An IXP team conducts a specialized technical review (Chapter 20) after a software increment is delivered. Called a retrospective, the review examines "issues, events, and lessons-learned" across a software increment and/or the entire software release.

Test-driven management.

An IXP team establishes a series of measurable "destinations" that assess progress to date and then defines mechanisms for determining whether or not these destinations have been reached.

Stakeholder

An individual, group, or organization who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project.

Planning

Any complicated journey can be simplified if a map exists. A software project is a complicated journey, and the planning activity creates a "map" that helps guide the team as it makes the journey. The map—called a software project plan—defines the software engineering work by describing the technical tasks to be conducted, the risks that are likely, the resources that will be required, the work products to be produced, and a work schedule.

Travel light.

As software engineering work proceeds, keep only those models that will provide long-term value and jettison the rest. Every work product that is kept must be maintained as changes occur.

Scrum set of development activities

Backlog— Sprints— Scrum meetings—

XP Planning Game

Begins with listening— requirements gathering activity that enables the technical members of the XP team to understand the business context for the software and to get a broad feel for required output and major features and functionality. Listening leads to the creation of a set of "stories" (also called user stories) that describe required output, features, and functionality for software to be built. Customers and developers work together to decide how to group stories into the next release (the next software increment) to be developed by the XP team.

Resulting Context.

Describes the conditions that will result once the pattern has been successfully implemented. Upon completion of the pattern: (1) What organizational or team-related activities must have occurred? (2) What is the exit state for the process? (3) What software engineering information or project information has been developed?

Initial Context.

Describes the conditions under which the pattern applies. Prior to the initiation of the pattern: (1) What organizational or team-related activities have already occurred? (2) What is the entry state for the process?(3) What software engineering information or project information already exists?

PSP High level design

External specifications for each component to be constructed are developed and a component design is created. Prototypes are built when uncertainty exists. All issues are recorded and tracked

PSP High level design review

Formal verification methods are applied to uncover errors in the design. Metrics are maintained for all important tasks and work results

What is the work product?

From the point of view of a software engineer, the work product is the set of programs, content (data), and other work products that are computer software. But from the user's viewpoint, the work product is the resultant information that somehow makes the user's world better.

Testable

In properly done agile, all code is tested code

Configuration and project management.

In the context of AUP, configuration management addresses change management, risk management, and the control of any persistent work products that are produced by the team. Project management tracks and controls the progress of the team and coordinates team activities.

Independent

Independence means that a story can be developed, tested, and potentially even delivered, on its own. Therefore, it can also be independently Valued.

INVEST in Good User Stories

Independent Negotiable Valuable Estimable Small Testable

Why is software engineering important?

It is important because it enables us to build complex systems in a timely manner and with high quality. It imposes discipline to work that can become quite chaotic, but it also allows the people who build computer software to adapt their approach in a manner that best suits their needs.

AUP Testing.

Like XP, the team designs and executes a series of tests to uncover errors and ensure that the source code meets its requirements.

Deployment.

Like the generic process activity discussed in Chapters 3, deployment in this context focuses on the delivery of a software increment and the acquisition of feedback from end users.

Content is more important than representation.

Modeling should impart information to its intended audience. A syntactically perfect model that imparts little useful content is not as valuable as a model with flawed notation that nevertheless provides valuable content for its audience.

AUP Implementation

Models are translated into source code.

Unified Modeling Language (UML)

Preferred method for representing analysis and design models.

Agility and the cost of change

Proponents of agility argue that a well-designed agile process "flattens" the cost of change curve, allowing a software team to accommodate changes late in a software project without dramatic cost and time impact.

Related Patterns.

Provide a list of all process patterns that are directly related to this one. This may be represented as a hierarchy or in some other diagrammatic form. For example, the stage pattern Communication encompasses the task patterns: ProjectTeam, CollaborativeGuidelines, ScopeIsolation, RequirementsGathering, ConstraintDescription, and ScenarioCreation.

Software Engineering Tools

Provide automated or semi-automated support for the process and the methods. When tools are integrated so that information created by one tool can be used by another, a system for the support of software development, called computer-aided software engineering, is established.

Process Model

Provides a specific roadmap for software engineering work. It defines the flow of all activities, actions and tasks, the degree of iteration, the work products, and the organization of the work that must be done. Why is it important? Because process provides stability, control, and organization to an activity that can, if left uncontrolled, become quite chaotic. However, a modern software engineering approach must be "agile." It must demand only those activities, controls, and work products that are appropriate for the project team and the product that is to be produced.

rules for writing software functions:

Rule 1: Do one thing Rule 2: Keep them small Rule 3: Make them smaller than that

Four Common agile methods

Scrum, DSSD, Agile Modeling (AM), Agile Unified Process (AUP)

Small

Size to be able to be completed in an iteration, otherwise they can't provide any value or be considered done at that point.

What is software engineering?

Software engineering is an engineering discipline that is concerned with all aspects of software production. encompasses a process, a collection of methods (practice) and an array of tools that allow professionals to build high-quality computer software.

The concurrent development model

Sometimes called concurrent engineering, defines a series of events that will trigger transitions from state to state for each of the software engineering activities, actions, or tasks. Rather than confining software engineering activities, actions, and tasks to a sequence of events, it defines a process network.

Readiness assessment.

The IXP team ascertains whether all members of the project community (e.g., stakeholders, developers, management) are on board, have the proper environment established, and understand the skill levels involved.

Project chartering.

The IXP team assesses the project itself to determine whether an appropriate business justification for the project exists and whether the project will further the overall goals and objectives of the organization.

Project community.

The IXP team determines whether the right people, with the right skills and training have been staged for the project. The "community" encompasses technologists and other stakeholders.

Continuous learning.

The IXP team is encouraged (and possibly, incented) to learn new methods and techniques that can lead to a higher-quality product.

PSP Development

The component level design is refined and reviewed. Code is generated, reviewed, compiled, and tested. Metrics are maintained for all important tasks and work results

Forces

The environment in which the pattern is encountered and the issues that make the problem visible and may affect its solution.

Adapt locally.

The modeling approach should be adapted to the needs of the agile team.

Phases of the Unified Process

The phases do not occur in a sequence, but rather with staggered concurrency. Inception, Elaboration, Construction, Transition

Deployment

The software (as a complete entity or as a partially completed increment) is delivered to the customer who evaluates the delivered product and provides feedback based on the evaluation.

Use multiple models.

There are many different models and notations that can be used to describe software. Only a small subset is essential for most projects. AM suggests that to provide needed insight, each model should present a different aspect of the system and only those models that provide value to their intended audience should be used.

PSP Planning

This activity isolates requirements and develops both size and resource estimates. In addition, a defect estimate (the number of defects projected for the work) is made. All metrics are recorded on worksheets or templates. Finally, development tasks are identified and a project schedule is created

The Spiral Model

This model encourages constant improvements as each phase is repeated several times as the solution becomes more and more complete. An evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model. It provides the potential for rapid development of increasingly more complete versions of the software.

AUP Modeling.

UML representations of the business and problem domains are created. However, to stay agile, these models should be "just barely good enough" to allow the team to proceed.

Know the models and the tools you use to create them.

Understand the strengths and weaknesses of each model and the tools that are used to create it.

Extreme Programming (XP)

Uses an object-oriented approach as its preferred development paradigm and encompasses a set of rules and practices that occur within the context of four framework activities: planning, design, coding, and testing.

Scrum

Uses small teams to produce small pieces of deliverable software using sprints, or 30-day intervals, to achieve an appointed goal

What are the steps of Software Engineering?

You build computer software like you build any successful product, by applying an agile, adaptable process that leads to a high-quality result that meets the needs of the people who will use the product. You apply a software engineering approach.

Legacy System

a current or existing system that will become the base for upgrading or integrating with a new system.

Backlog—

a prioritized list of project requirements or features that provide business value for the customer. Items can be added to the backlog at any time (this is how changes are introduced). The product manager assesses the back- log and updates priorities as required.

Agile Unified Process (AUP)

adopts a "serial in the large" and "iterative in the small" philosophy for building computer-based systems. By adopt- ing the classic UP phased activities—inception, elaboration, construction, and transition—AUP provides a serial overlay (i.e., a linear sequence of software engineering activities) that enables a team to visualize the overall process flow for a software project. However, within each of the activities, the team iterates to achieve agility and to deliver meaningful software increments to end users as rapidly as possible. Each AUP iteration addresses the following activities: Modeling, Implementation, Deployment, Configuration and project management.

Process Technology Tool

allow a software organization to build an automated model of the process framework, task sets, and umbrella activities. The model, normally represented as a network, can then be analyzed to determine typical workflow and examine alternative process structures that might lead to reduced development time or cost.

Process Pattern

describes a process-related problem that is encountered during software engineering work, identifies the environment in which the problem is encountered, and suggests that one or more proven solutions to the problem. It provides you with a template, a consistent method for describing problem solutions within the context of the software process.

A task

focuses on a small, but well-defined objective (e.g., conducting a unit test) that produces a tangible outcome.

User Story

is a brief statement of intent that describes something the system needs to do for the user. Examples: Log in to my web energy-monitoring portal See my daily energy usage Check my current electricity billing rate

A persistent work product

is a model or document or test case produced by the team that will be kept for an indeterminate period of time. It will not be discarded once the software increment is delivered.

Dynamic Systems Development Method (DSDM)

is an agile software development approach that "provides a framework for building and maintain- ing systems which meet tight time constraints through the use of incremental prototyping in a controlled project environment - is an iterative software process in which each iteration follows the 80 percent rule. That is, only enough work is required for each increment to facilitate movement to the next increment. The remaining detail can be completed later when more business requirements are known or changes have been requested and accommodated.

Industrial XP (IXP)

is an organic evolution of XP. It is imbued with XP's minimalist, customer-centric, test-driven spirit. IXP differs most from the original XP in its greater inclusion of management, its expanded role for customers, and its upgraded technical practices." IXP incorporates six new practices that are designed to help ensure that an XP project works successfully for significant projects within a large organization: - Readiness Assessment - Project Community - Project Chartering - Test-driven management - Restrospectives - Continuous learning

Value

is the most important attribute in the INVEST model and every user story must provide some value to the user, customer, or stakeholder of the product. Backlogs are prioritized by value and businesses succeed or fail based on the value the teams can deliver.

Artificial intelligence software—

makes use of nonnumerical algorithms to solve complex problems that are not amenable to computation or straightforward analysis. Applications within this area include robotics, expert systems, pattern recognition (image and voice), artificial neural networks, theorem proving, and game playing.

Software configuration management—

manages the effects of change throughout the software process.

V-model

modified Waterfall model that provides for back references for VERIFICATION and VALIDATION

Implementation—

places the latest software increment (an "operationalized" prototype) into the operational environment. It should be noted that (1) the increment may not be 100 percent complete or (2) changes may be requested as the increment is put into place. In either case, DSDM development work continues by returning to the functional model iteration activity.

Functional model iteration—

produces a set of incremental prototypes that demonstrate functionality for the customer. (Note: All DSDM prototypes are intended to evolve into the deliverable application.) The intent during this iterative cycle is to gather additional requirements by eliciting feedback from users as they exercise the prototype.

Team Software Process (TSP) framework activities:

project launch, high-level design, implementation, integration and test, and postmortem.

Design and build iteration—

revisits prototypes built during the functional model iteration to ensure that each has been engineered in a manner that will enable it to provide operational business value for end users. In some cases, the functional model iteration and the design and build iteration occur concurrently.

Estimable

to draw out any hidden assumptions, missing acceptance criteria, and to clarify the team's shared understanding of the story. The ability to estimate a user story is highly influenced by the size of the story.

Process Flow

describes how the framework activities and the actions and tasks that occur within each framework activity are organized with respect to sequence and time. - A linear process flow executes each of the five framework activities in sequence, beginning with communication and culminating with deployment. - An iterative process flow repeats one or more of the activities before proceeding to the next - An evolutionary process flow executes the activities in a "circular" manner. Each circuit through the five activities leads to a more complete version of the software - A parallel process flow executes one or more activities in parallel with other activities (e.g., modeling for one aspect of the software might be executed in parallel with the construction of another aspect of the software).

Product-line software —

designed to provide a specific capability for use by many different customers. Product-line software can focus on a limited and esoteric marketplace (e.g., inventory control products) or address mass consumers. The concept of a line of software products that are related in some way is not new. But the idea that a line of software products, all developed using the same underlying application and data architectures, and all implemented using a set of reusable software components that can be reused across the product line provides signifi cant engineering leverage.

Construction Phase of the UP

develops or acquires the software components that will make each use case operational for end users. As components are being implemented, unit tests are designed and executed for each. In addition, integration activities (component assembly and integration testing) are conducted.

Work product preparation and production—

encompass the activities required to create work products such as models, documents, logs, forms, and lists.

The formal methods model

encompasses a set of activities that leads to formal mathematical specification of computer software. Formal methods enable you to specify, develop, and verify a computer-based system by applying a rigorous, mathematical notation.

Transition Phase of the UP

encompasses the latter stages of the generic construction activity and the first part of the generic deployment (delivery and feedback) activity. Software is given to end users for beta testing, and user feed- back reports both defects and necessary changes. In addition, the software team creates the necessary support information (e.g., user manuals, troubleshooting guides, installation procedures) that is required for the release. At the conclusion of the transition phase, the software increment becomes a usable software release.

If the project was considerably more complex with many stakeholders, each with a different set of (sometimes conflicting) requirements, the communication activity might have six distinct actions (described in Chapter 8):

inception, elicitation (requirements gathering), elaboration, negotiation, specification, and validation. Each of these soft-ware engineering actions would have many work tasks and a number of distinct work products.

component-based development model

incorporates many of the characteristics of the spiral model.

A process

is a collection of activities, actions, and tasks that are performed when some work product is to be created. An activity strives to achieve a broad objective (e.g., communication with stakeholders) and is applied regardless of the application domain, size of the project, complexity of the effort, or degree of rigor with which software engineering is to be applied.

Aspect-Oriented Software Development

often referred to as aspect-oriented programming (AOP) or aspect-oriented component engineering (AOCE), is a relatively new software engineering paradigm that provides a process and methodological approach for defining, specifying, designing, and constructing aspects—"mechanisms beyond subroutines and inheritance for localizing the expression of a crosscutting concern."

IEEE [IEE93a] has developed the following definition for software engineering:

(1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1).

Software is:

(1) instructions (computer programs) that when executed provide desired features, function, and performance; (2) data structures that enable the programs to adequately manipulate information, and (3) descriptive information in both hard copy and virtual forms that describes the operation and use of the programs. Software is a logical rather than a physical system element. Therefore, the software has one fundamental characteristic that makes it considerably different from hardware: Software doesn't "wear out." But it does deteriorate.

An action

(e.g., architectural design) encompasses a set of tasks that produce a major work product (e.g., an architectural model).

The essence of software engineering practice:

(i) understand the problem (communication and analysis) (ii) plan a solution (modeling and software design) (iii) carry out the plan (code generation) (iv) Examine the result for accuracy (testing and quality assurance)

Regardless of the technology that is used to create the components, the component-based development model incorporates the following steps (implemented using an evolutionary approach):

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

Personal Software Process (PSP)

- Emphasizes personal measurement of both work products and quality of work products - Stresses the importance of identifying errors early and to understand the types of errors Planning, High-level design, High-level design review, Development, Postmortem

Among the problems that are sometimes encountered when the waterfall model is applied are:

- Real projects rarely follow the sequential flow that the model proposes. Although the linear model can accommodate iteration, it does so indirectly. As a result, changes can cause confusion as the project team proceeds. - It is often difficult for the customer to state all requirements explicitly. The waterfall model requires this and has difficulty accommodating the natural uncertainty that exists at the beginning of many projects. - The customer must have patience. A working version of the program(s) will not be available until late in the project time span. A major blunder, if undetected until the working program is reviewed, can be disastrous.

Key Points CH 1

- Software is both a product and a vehicle that delivers a product. - Software engineering methods strive to reduce the magnitude of the spikes and the slope of the failure curves for software.

Process Assessment and Improvement

- Standard CMMI (Capability Maturity Model Integration) Assessment Method for Process Improvement (SCAMPI) - CMM-Based Appraisal for Internal Process Improvement (CBA IPI) - SPICE (ISO/IEC15504) - ISO 9001:2000 for Software

Although not a mainstream approach, the formal methods model offers the promise of defect-free software. Yet, concern about its applicability in a business environment has been voiced:

- The development of formal models is currently quite time consuming 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.

Key Points CH 4

- The purpose of process models is to try to reduce the chaos present in developing new software products. - Prescriptive process models define a prescribed set of process elements and predictable process workflow. - The V-model illustrates how verification and validation actions are associated with earlier engineering actions. - The incremental model delivers a series of releases, called increments, that provide progressively more functionality for the customer as each increment is delivered. - Evolutionary process models produce an increasingly more complete version of the software with each iteration. - The spiral model can be adapted to apply throughout the entire life cycle of an application, from concept development to maintenance. - Project plans must be viewed as living documents; progress must be assessed often and revised to take changes into account. - AOSD defines "aspects" that express customer concerns that cut across multiple system functions, features, and information. - UP phases are similar in intent to the generic framework activities defined in this book. - PSP emphasizes the need to record and analyze the types of errors you make so that you can develop strategies to eliminate them. - TSP scripts define elements of the team process and activities that occur within the process. -

Key Points CH 2

- Understand the problem before you build a solution - Both quality and maintainability are on the outgrowth of good design - Software engineering encompasses a process, methods for managing and engineering software, and tools. - Umbrella activities occur throughout the software process and focus primarily on project management, tracking, and control. - Software process adaptation is essential for project success. - If software has value, it will change over its useful life. For that reason, the software must be built to be maintainable.

Inception Phase of the UP

- phase where you define system goals, determine scope (document it to avoid scope creep), and assess feasibility (cost, schedule, technology etc.) - encompasses both customer communication and planning activities. By collaborating with stakeholders, business requirements for the software are identified; a rough architecture for the system is proposed; and a plan for the iterative, incremental nature of the ensuing project is developed. Fundamental business requirements are described through a set of preliminary use cases that describe which features and functions each major class of users desires.

Prototyping can be problematic for the following reasons:

1. Stakeholders see what appears to be a working version of the software, unaware that the prototype is held together haphazardly, unaware that in the rush to get it working you haven't considered overall software quality or long-term maintainability. When informed that the product must be re- built so that high levels of quality can be maintained, stakeholders cry foul and demand that "a few fixes" be applied to make the prototype a working product. Too often, software development management relents. 2. As a software engineer, you often make implementation compromises in order to get a prototype working quickly. An inappropriate operating system or programming language may be used simply because it is

Umbrella Activities

Applied throughout a software project and help a software team manage and control progress, quality, change, and risk, includes: - Software project tracking and control - Risk management - Software quality assurance - Technical reviews - Measurement - Software configuration management - Reusability management - Work product preparation and production

Communication

Before any technical work can commence, it is critically important to communicate and collaborate with the customer (and other stake- holders).3 The intent is to understand stakeholders' objectives for the project and to gather requirements that help define software features and functions.

A generic Process Framework for software engineering encompasses five activities:

Communication Planning Modeling Construction Deployment

Commercial off-the-shelf (COTS) software components

Developed by vendors who offer them as products, provide targeted functionality with well-defined interfaces that enable the component to be integrated into the software that is to be built.

Cloud Computing

Encompasses an infrastructure or "ecosystem" that enables any user, anywhere, to use a computing device to share computing resources on a broad scale. Computing devices reside outside the cloud and have access to a variety of resources within the cloud. These resources encompass applications, platforms, and infrastructure. In its simplest form, an external computing device accesses the cloud via a Web browser or analogous software. The cloud provides access to data that resides with databases and other data structures. In addition, devices can access executable applications that can be used in lieu of apps that reside on the computing device.

Elaboration phase of the UP

Encompasses the communication and modeling activities of the generic process model. Refines and expands the preliminary use cases that were developed as part of the inception phase and expands the architectural representation to include five different views of the software—the use case model, the analysis model, the design model, the implementation model, and the deployment model. In some cases, elaboration creates an "executable architectural baseline" that represents a "first cut" executable system.

WebApps

Involve[d] a mixture between print publishing and software development, between marketing and computing, between internal communications and external relations, and between art and technology. Provide full computing potential in many of the application categories.

Software Development Myths

Management Myths - belief that lessen the pressure (even temporarily) Customer Myths - Leads to false expectations (by the customer) and, ultimately, dissatisfaction with the developer. Practitioner's Myths - Old ways and attitudes die hard

Process of adaptation

Previously in this section, we noted that the software engineering process is not a rigid prescription that must be followed dogmatically by a software team. Rather, it should be agile and adaptable (to the problem, to the project, to the team, Software process adaptation is essential for project success. and to the organizational culture). Therefore, a process adopted for one project might be significantly different than a process adopted for another project. Among the differences are - Overall flow of activities, actions, and tasks and the interdependencies among them. - Degree to which actions and tasks are defined within each framework activity. - Degree to which work products are identified and required. - Manner in which quality assurance activities are applied. - Manner in which project tracking and control activities are applied. - Overall degree of detail and rigor with which the process is described. - Degree to which the customer and other stakeholders are involved with the project. - Level of autonomy given to the software team. - Degree to which team organization and roles are prescribed.

Software Engineering Methods

Provide the technical how-to's for building software. Methods encompass a broad array of tasks that include communication, requirements analysis, design modeling, program construction, testing, and support.

Mobile Applications

Software programs that run on mobile devices and give users access to certain content, specifically designed to reside on a mobile platform (e.g., iOS, Android, or Windows Mobile). In most instances, mobile applications encompass a user interface that takes advantage of the unique interaction mechanisms provided by the mobile platform, interoperability with Web-based resources that provide access to a wide array of information that is relevant to the app, and local processing capabilities that collect, analyze, and format information in a manner that is best suited to the mobile platform. In addition, a mobile app provides persistent storage capabilities within the platform. A mobile web application (WebApp) allows a mobile device to gain access to web-based content via a browser that has been specifically designed to accommodate the strengths and weaknesses of the mobile platform. A mobile app can gain direct access to the hardware characteristics of the device (e.g., accelerometer or GPS location) and then provide the local processing and storage capabilities noted earlier. As time passes, the distinction between mobile WebApps and mobile apps will blur as mobile browsers become more sophisticated and gain access to device level hardware and information.

Waterfall model

Sometimes called the Classic Life Cycle and the oldest paradigm for software engineering. It suggests a systematic, sequential approach to software development that begins with customer specification of requirements and progresses through planning, modeling, construction, and deployment, culminating in the ongoing support of the completer software.

seven broad categories of computer software present continuing challenges for software engineers:

System Software Application Software Engineering/Scientific Software Artificial Intelligence Web/Mobile Application Embedded Software Product-line software

Team Software Process (TSP)

The goal is to build a "self-directed" project team that organizes itself to produce high-quality software. Objectives: - Build self-directed teams that plan and track their work, establish goals, and own their processes and plans. These can be pure software teams or integrated product teams (IPTs) of 3 to about 20 engineers. - Show managers how to coach and motivate their teams and how to help them sustain peak performance. - Accelerate software process improvement by making CMM level 5 behavior normal and expected. - Provide improvement guidance to high-maturity organizations. - Facilitate university teaching of industrial-grade team skills.

David Hooker [Hoo96] has proposed seven principles that focus on software engineering practice as a whole.

The First Principle: The Reason It All Exists - to provide value to its users. The Second Principle: KISS (Keep It Simple, Stupid!) - All design should be as simple as possible, but no simpler, easily understood and easily maintained system. The Third Principle: Maintain the Vision - A clear vision is essential to the success of a software project. Having an empowered architect who can hold the vi- sion and enforce compliance helps ensure a very successful software project. The Fourth Principle: What You Produce, Others Will Consume - always specify, design, and implement knowing someone else will have to understand what you are doing. Someone may have to debug the code you write, and that makes them a user of your code. Making their job easier adds value to the system. The Fifth Principle: Be Open to the Future - Never design yourself into a corner. Always ask "what if," and prepare for all possible answers by creating systems that solve the general problem, not just the specific one. This could very possibly lead to the reuse of an entire system. The Sixth Principle: Plan Ahead for Reuse - Reuse saves time and effort. It reduces the cost and increases the value of both the reusable components and the systems into which they are incorporated. The Seventh Principle: Think! - Placing clear, complete thought before action almost always produces better results.

Pattern Name

The pattern is given a meaningful name describing it within the context of the software process (e.g., TechnicalReviews).

Type.

The pattern type is specified. Suggested three types: 1. Stage pattern— defines a problem associated with a framework activity for the process. Since a framework activity encompasses multiple actions and work tasks, a stage pattern incorporates multiple task patterns (see the following) that are relevant to the stage (framework activity). An example of a stage pattern might be EstablishingCommunication. This pattern would incorporate the task pattern RequirementsGathering and others. 2. Task pattern— defines a problem associated with a software engineering action or work task and relevant to successful software engineering practice (e.g., RequirementsGathering is a task pattern). 3. Phase pattern—define the sequence of framework activities that occurs within the process, even when the overall flow of activities is iterative in nature. An example of a phase pattern might be SpiralModel or Prototyping.

Software engineering layers

Tools, Methods, Process, A quality focus

PSP Postmortem

Using the measures and metrics collected (this is a substantial amount of data that should be analyzed statistically), the effectiveness of the process is determined. Measures and metrics should provide guidance for modifying the process to improve its effectiveness.

Construction

What you design must be built. This activity combines code generation (either manual or automated) and the testing that is required to uncover errors in the code.

Blocking States

Where some project team members must wait for other members of the team to complete dependent tasks

Modeling

Whether you're a landscaper, a bridge builder, an aeronautical engineer, a carpenter, or an architect, you work with models every day. You create a "sketch" of the thing so that you'll understand the big picture—what it will look like architecturally, how the constituent parts fit together, and many other characteristics. If required, you refine the sketch into greater and greater detail in an effort to better understand the problem and how you're going to solve it. A software engineer does the same thing by creating models to better understand software requirements and the design that will achieve those requirements.

Engineering/scientific software —

a broad array of "number-crunching programs that range from astronomy to volcanology, from automotive stress analysis to orbital dynamics, and from computer-aided design to molecular biology, from genetic analysis to meteorology.

System software—

a collection of programs written to service other programs. Some system software (e.g., compilers, editors, and file management utilities) processes complex, but determinate, information structures. Other systems applications (e.g., operating system components, drivers, networking software, telecommunications processors) process largely indeterminate data. Software is determinate if the order and timing of inputs, processing, and outputs is predictable. Software is indeterminate if the order and timing of inputs, processing, and outputs cannot be predicted in advance.

ISO 9001:2000 for Software

a generic standard that applies to any organization that wants to improve the overall quality of the products, systems, or services that it provides. Therefore, the standard is directly applicable to software organizations and companies [Ant06].

Prototyping

a modern design approach where the designers and system users use an iterative approach to building the system Ideally, it serves as a mechanism for identifying software requirements and "the first system." - communication - quick plan - Modeling Quick design - Construction of prototype - Deployment Delivery and Feedback

A process framework

a set of guidelines, work products, and tools that attempt to facilitate a process. Establishes the foundation for a complete software engineering process by identifying a small number of framework activities that are applicable to all software projects, regardless of their size or complexity. In addition, the process framework encompasses a set of umbrella activities that are applicable across the entire software process.

SPICE (ISO/IEC15504)

a standard that defines a set of requirements for software process assessment. The intent of the standard is to assist organizations in developing an objective evaluation of the efficacy of any defined software process [ISO08].

Software project tracking and control—

allows the software team to assess progress against the project plan and take any necessary action to maintain the schedule.

CMM-Based Appraisal for Internal Process Improvement (CBA IPI)

provides a diagnostic technique for assessing the relative maturity of a software organization; uses the SEI CMM as the basis for the assessment [Dun01].

Standard CMMI Assessment Method for Process Improvement (SCAMPI)

provides a five-step process assessment model that incorporates five phases: initiating, diagnosing, establishing, acting, and learning. The SCAMPI method uses the SEI CMMI as the basis for assessment [SEI00].

Embedded software—

resides within a product or system and is used to implement and control features and functions for the end user and for the system itself. Embedded software can perform limited and esoteric functions (e.g., key pad control for a microwave oven) or provide significant function and control capability (e.g., digital functions in an automobile such as fuel control, dashboard displays, and braking systems).

Application software —

stand-alone programs that solve a specific business need. Applications in this area process business or technical data in a way that facilitates business operations or management/technical decision making.

Production Phase of the UP

the deployment activity of the generic process. During this phase, the ongoing use of the software is monitored, support for the operating environment (infrastructure) is provided, and defect reports and requests for changes are submitted and evaluated.

Web/Mobile applications —

this network-centric software category spans a wide array of applications and encompasses both browser-based apps and software that resides on mobile devices.

legacy systems often evolve for one or more of the following reasons:

• The software must be adapted to meet the needs of new computing environments or technology. • The software must be enhanced to implement new business requirements. • The software must be extended to make it interoperable with other more modern systems or databases. • The software must be re-architected to make it viable within a evolving computing environment.