Fundamentals to Software Engineering - first exam study (chapter 1 - 5)

Safety-critical software is usually developed with?

usually developed using a waterfall process as lots of analysis and documentation is required before implementation begins

Validation

test activity that checks that software meets the needs and expectation of the customer "Checks that we have the right requirements for the customer"

Verification

test activity that checks that the software meets its specification

A note on Reuse-Oriented Development

- There will likely always be some reuse on your projects ⚫ Informal - ad hoc, opportunistic ⚫ Formal - planned reuse (requirements, designs, code, tests, user manual, etc.) - 3 types of component reuse typical ⚫ Full applications ⚫ Collections of objects or modules as part of a component ⚫ Services

Spiral Development

-A hybrid model where the development of the system spirals outward from an initial outline through to the final developed system -Each spiral loop represents a 'phase' of the software process -Came along in the 1990s -Example: the innermost loop might be concerned with system feasibility; next loop might be concerned with system requirements; next loop with system design, and so on.

Software Process

-A set of activities and associates results, which is organized in stages of the product, which leads to the production of the software product.

Advantages and Challenges of Evolutionary Development

-Advantages *Happier customers since you can help them define the requirements *Flexibility in modifying requirements *Prototypes are very visual and simple; hence few ambiguities -Challenges *Hard to trace the "process" due to the ad-hoc nature of evolutionary development *Systems are often poorly structured *Special tools and techniques may be required for rapid development that may be incompatible with the usual development environment *Not cost-effective to product "documents" *Do we really "throw-away" the throw-away prototype?

Waterfall Model:

-Conducted in stand-alone phases; a plan-driven software process model. -In principle, the next phase does not start until previous phase completes (in practice, the phases overlap and there is feedback) Basically each step is stand-alone, so we start at a step at a time. -First created in 1970 by Royce -Presents the software development process by number of stages -The stages of the waterfall model directly reflect the fundamental software development activities: 1. Requirements analysis and definition: The system's services, constraints, and goals are established by consultation with system users. They are then defined in detail and serve as a system specification. 2. System and software design: The systems design process allocates the requirements to either hardware or software systems. It establishes an overall system architecture. Software design involves identifying and describing the fundamental software system abstractions and their relationships. 3. Implementation and unit testing: During this stage, the software design is realized as a set of programs or program 4. Integration and system testing: The individual program units or programs are integrated and tested as a complete system to ensure that the software requirements have been met. After testing, the software system is delivered to the customer. 5. Operation and maintenance: Normally, this is the longest life-cycle phase. The system is installed and put into practical use. Maintenance involves correcting errors that were not discovered in earlier stages of the life cycle, improving the implementation of system units, and enhancing the system's services as new requirements are discovered. -The waterfall model is an example of a plan-driven process. In principle at least, you should plan and schedule all of the activities before starting software development -The following phase should not start until the previous phase has finished.

Spiral Development Loops

-Each loop in the spiral is split into four sectors: 1) Object Setting - set specific objectives for that phase 2) Risk-assessment and reduction - identify and work suspected problems that might affect the development schedule, cost, or technical solution 3)Development and validation - select a development model based on risk levels; develop product 4. Planning - decide if a next loop is required and what will be needed

The Waterfall Model is only appropriate for systems like:

-Embedded systems -Critical systems -Large Software systems

Hybrid software process models:

-Incremental development -Spiral Development -SCRUM

SCRUM Agile Process

-Incremental rapid approach to produce software within a predictable amount of time with risk tolerance *Includes Scrum Master, Product Owner, and Tema roles *15-minute daily stand-up meeting to improve communication usually done in the morning *Team retrospect at end to improve process "What did we do bad, what did we do good, what can we do better next time?" *Product backlog (requirements, features) *2 to 4 week development iterations, called "Sprints") -Scrum is broken down into shorter sprints and smaller deliverables, while in Agile everything is delivered at the end of the project. Agile involves members from various cross-functional teams, while a Scrum project team includes specific roles, such as the Scrum Master and Product Owner.

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. *Goal: 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 waterfall model, process activities are organized in sequences *In incremental development, process activities are interleaved -The software product type, project environment, and skill level of teams drive how these basic process activities are done

Scrum Agile Process Typical Outline

-Release planning -Product Backlog -Sprint Planning -Sprint Backlog **Will take 2-4 Weeks** -Daily Scrum Meeting (15 minutes long) -Sprint Retrospection -Potentially Shippable Product Increment

Reuse-Oriented Development

-Reuse-oriented approach relies on a large base of reusable software components -Design system to capitalize on the existing components

Formal Systems Development

-Similar to Waterfall model but development is based on formal mathematical transformation of system specification to an executable program *Software requirements specifications is refined into detailed formal specification, which is expressed in mathematical notion. *Design, implementation, and testing are replaced by a series of mathematical transformations -Requires specialized expertise with software development team -Usually used where safety is required like Europe -Not really much done in the U.S., but done in Europe often

Software Validation

-Software validation is also referred to V&V, which is verification and validation. -Software validation's purpose is to ensure that the system both conforms and satisfies to the specification and customer expectations. -Software validation may also include where you check processes, such as inspections and reviews from each stage of the software stage to meet the user's definition and requirements to program development. -Program testing is also used for validation where the system pulls stimulated data, which is the principal of the validation technique.

Advantages of Incremental Development

-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

Issues of Incremental Development

-The process is "not visible" -Managers need regular deliveries to measure the progress of the product *If systems are developed quickly, it is not cost-effective to produce or update documents that reflect every version of the system *System development outpaces documentation -Large organization have bureaucracy to overcome -more formal processes rather than agile and somewhat informal *There could be additional requirements (safely, certification, etc.) built into the process but not universally known *Large teams, long-lived development create organization angst -System structure tends to degrade as new increments are added *Unless time and money is spent on 'refactoring' to improve the software, regular chance tends to corrupt the structure, inject defects - Incorporating further software changes become increasingly difficult and costly as degradation continues -Refactoring wastes time and it gets harder and harder to refactor the product as the product continues to grow. Software engineers get paid to add new features

Software Process Models:

-Waterfall model: Start at stand-alone phases step by step -Incremental development -Evolutionary development -Formal systems development -Reuse-based development

What are two approaches to reduce the cost of rework?

1)Change anticipation: The software process includes activities that can anticipate or predict 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. They can experiment with the prototype and refine their requirements before committing to high software production costs. 2)Change tolerance: The process and software are designed so that changes can be easily made to the system. 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 to be altered to incorporate the change.

What are the two ways to cope with change and changing system requirements?

1)System prototyping: A version of the system or part of the system is developed quickly to check the customer's requirements and the feasibility of design decisions. This is a method of change anticipation as it allows users to experiment with the system before delivery and so refine their requirements. The number of requirements change proposals made after delivery is therefore likely to be reduced. 2)Incremental delivery: System increments are delivered to the customer for comment and experimentation. This supports both change avoidance and change tolerance. It avoids the premature commitment to requirements for the whole system and allows changes to be incorporated into later increments at relatively low cost.

Process Maturity Standard

1. Initial 2.Defined 3.Managed 4.Quantively managed 5.Optimized

What are the levels in the process maturity level?

1. Initial The goals associated with the process area are satisfied, and for all processes the scope of the work to be performed is explicitly set out and communicated to the team members. 2. Managed At this level, the goals associated with the process area are met, and organizational policies are in place that define when each process should be used. There must be documented project plans that define the project goals. Resource management and process monitoring procedures must be in place across the institution. 3. Defined This level focuses on organizational standardization and deployment of processes. Each project has a managed process that is adapted to the project requirements from a defined set of organizational processes. Process assets and process measurements must be collected and used for future process improvements. 4. Quantitatively managed At this level, there is an organizational responsibility to use statistical and other quantitative methods to control subprocesses. That is, collected process and product measurements must be used in process management. 5. Optimizing At this highest level, the organization must use the process and product measurements to drive process improvement. Trends must be analyzed and the processes adapted to changing business needs.

General process model for reusable software development:

1. Requirements specification The initial requirements for the system are proposed. These do not have to be elaborated in detail but should include brief descriptions of essential requirements and desirable system features. 2. Software discovery and evaluation Given an outline of the software requirements, a search is made for components and systems that provide the functionality required. Candidate components and systems are evaluated to see if they meet the essential requirements and if they are generally suitable for use in the system. 3. Requirements refinement During this stage, the requirements are refined using information about the reusable components and applications that have been discovered. The requirements are modified to reflect the available components, and the system specification is re-defined. Where modifications are impossible, the component analysis activity may be reentered to search for alternative solutions. 4. Application system configuration If an off-the-shelf application system that meets the requirements is available, it may then be configured for use to create the new system. 5. Component adaptation and integration If there is no off-the-shelf system, individual reusable components may be modified and new components developed. These are then integrated to create the system.

Integration and configuration - Three types of software components are frequently reused:

1. Stand-alone application systems that are configured for use in a particular environment. These systems are general-purpose systems that have many features, but they have to be adapted for use in a specific application. 2. Collections of objects that are developed as a component or as a package to be integrated with a component framework such as the Java Spring framework (Wheeler and White 2013). 3. Web services that are developed according to service standards and that are available for remote invocation over the Internet.

What are the three main activities in the requirement engineering process?

1.Requirements elicitation and analysis: This is the process of deriving the system requirements through observation of existing systems, discussions with potential users and procurers, task analysis, and so on. This may involve the development of one or more system models and prototypes. These help you understand the system to be specified. 2.Requirements specification: Requirements specification is the activity of translating the information gathered during requirements analysis into a document that defines a set of requirements. Two types of requirements may be included in this document. User requirements are abstract statements of the system requirements for the customer and end-user of the system; system requirements are a more detailed description of the functionality to be provided. 3.Requirements validation: This activity checks the requirements for realism, consistency, and completeness. During this process, errors in the requirements document are inevitably discovered. It must then be modified to correct these problems.

Spiral Development - Advantages and Disadvantages

Advantages: -Explicit consideration of risks *Alternative solutions are evaluated in each cycle -More detailed processes for each development phase depending on the need Disadvantages: -Cost -Sometime difficult to implement or too time consuming -Risk shows up a lot more in Spiral Development than the others.

Advantages and Challenges of Reuse-Oriented Development

Advantages: -Known to be affordable so there is reduced cost and risk -Faster delivery (since not 'developing' reused SW) Challenges: -Requires a large enough reuse component base -May compromise on requirements (there are risks of not meeting user needs because SW doesn't 'cover' requirements) -Some control over the system evolution is lost as new versions of reusable components are not under the control of organization using the component -Potential issues in back/forward compatibility

Advantages of Waterfall Model

Advantages: -Simple to follow (sequential, linear) -Relatively simple to track progress (project management, "predictable development") -Good structural design Challenges: -In practice, phases overlap and iterate -Hard to modify and implement changes (requirements, designs) -Need nearly a complete set of requirements from customers at the project start (the biggest challenge) Waterfall appropriate for: -Embedded systems -Critical systems (safely, security, reliability, etc.) -Large systems with several partners, vendors, suppliers

What is the aim of the requirement engineer process?

Aims to produce an agreed requirements document that specifies a system satisfying stakeholder requirements. Requirements are usually presented at two levels of detail. End-users and customers need a high-level statement of the requirements; system developers need a more detailed system specification.

Software process model

An abstract representation of a software process

Important notes in waterfall model

As new information emerges in a process stage, the documents produced at previous stages should be modified to reflect the required system changes. For example, if it is discovered that a requirement is too expensive to implement, the requirements document should be changed to remove that requirement. However, this requires customer approval and delays the overall development process. As a result, both customers and developers may prematurely freeze the software specification so that no further changes are made to it. Unfortunately, this means that problems are left for later resolution, ignored, or programmed around. Premature freezing of requirements may mean that the system won't do what the user wants. It may also lead to badly structured systems as design problems are circumvented by implementation tricks.

What happens before the requirement engineers begin?

Before the requirements engineering process starts, a company may carry out a feasibility or marketing study to assess whether or not there is a need or a market for the software and whether or not it is technically and financially realistic to develop the software required. Feasibility studies are short-term, relatively cheap studies that inform the decision of whether or not to go ahead with a more detailed analysis

What is rework?

Change adds to the costs of software development because it usually means that work that has been completed has to be redone. This is called rework. For example, if the relationships between the requirements in a system have been analyzed and new requirements are then identified, some or all of the requirements analysis has to be repeated. It may then be necessary to redesign the system to deliver the new requirements, change any programs that have been developed, and retest the system.

Process Maturity Standard

Chapter 2 Slide 41

Software Design & Implementation Activities (relates to software specification activities)

Creating the design and structures to meet the requirements to the software specific activities ⚫ The process of converting the system specification into an executable system - Software design - Designs a software structure that realizes the 'requirements specification' - Implementation - Translates this software structure into an executable program ⚫ The activities of design and implementation are closely related and may be inter-leaved, iterated

Incremental Development

Develop an initial implementation, expose to users receive comments/feedback, & refine until satisfied -One of the most common approaches nowadays for application systems and software products *Can be plan-driven or agile approach -One of the fundamental components of agile development -Plan-driven, system increments defined in advance -Agile development, early increments are defined but later increments depend on the progress, reviews, and customer priorities -Incremental development is better than waterfall when requirements are changing during the development process. This would be the case for business systems and software products *Common for business systems, software products *Each increment delivers new functionality to evaluate and feedback to the development team -This development process creates numerous different types of versions and end when a version satisfies the customer's needs.

What are the two levels of detail of the requirements?

End-users and customers need a high-level statement of the requirements; system developers need a more detailed system specification.

Variant of the waterfall model

Formal system development: where a mathematical model of a system specification is created. This model is then refined, using mathematical transformations that preserve its consistency, into executable code. Formal development processes, such as that based on the B method (Abrial 2005, 2010), are mostly used in the development of software systems that have stringent safety, reliability, or security requirements. The formal approach simplifies the production of a safety or security case. This demonstrates to customers or regulators that the system actually meets its safety or security requirements. However, because of the high costs of developing a formal specification, this development model is rarely used except for critical systems engineering.

Important Notes

Generally, for large systems, you need to find a balance between plan-driven and agile processes.

Are all of the software processes organized in the same way like -Software Specification -Software Development -Software Validation -Software Evolution

How these activities are carried out depends on the type of software being developed, the experience and competence of the developers, and the type of organization developing the software.

In agile methods, are requirements specification a separate activity?

In agile methods, requirements specification is not a separate activity but is seen as part of system development. Requirements are informally specified for each increment of the system just before that increment is developed. Requirements are specified according to user priorities. The elicitation of requirements comes from users who are part of or work closely with the development team.

Is there a right or wrong type of software process to use?

In practice, most practical processes include elements of both plan-driven and agile approaches. There are no right or wrong processes.

How is the waterfall model organized

In the waterfall model they are organized in a sequence -Software Specification -Software Development -Software Validation -Software Evolution

Initial stage for process maturity standard

Level 1: processes unpredictable; poorly controlled and reactive. Software development is ad-hoc (default).

Important Notes

Parts of the system that are well understood can be specified and developed using a waterfall-based process or may be bought in as off-the-shelf systems for configuration. Other parts of the system, which are difficult to specify in advance, should always be developed using an incremental approach. In both cases, software components are likely to be reused

Prototype Process

Plan - Define - Develop - Evaluate -usually used to try out possible early design solutions

Process models are sometimes called?

Process maps

Other names for General Process Models

Process paradigms

For software design and implementation is programming individual

Programming is an individual activity, and there is no general process that is usually followed. Some programmers start with components that they understand, develop these, and then move on to less understood components. Others take the opposite approach, leaving familiar components till last because they know how to develop them. Some developers like to define data early in the process and then use this to drive the program development; others leave data unspecified for as long as possible. Normally, programmers carry out some testing of the code they have developed. This often reveals program defects (bugs) that must be removed from the program. Finding and fixing program defects is called debugging. Defect testing and debugging are different processes. Testing establishes the existence of defects. Debugging is concerned with locating and correcting these defects. When you are debugging, you have to generate hypotheses about the observable behavior of the program and then test these hypotheses in the hope of finding the fault that caused the output anomaly. Testing the hypotheses may involve tracing the program code manually. It may require new test cases to localize the problem. Interactive debugging tools, which show the intermediate values of program variables and a trace of the statements executed, are usually used to support the debugging process.

Define Ad hoc

Random testing, monkey testing, doing a task without a plan or documentation

Software evolution

The software must evolve to meet changing customer needs. The software will be enhanced/changed/maintenance

Software development

The software to meet the specification must be produced.

Software Specification Activities

Requirements Engineering is process of understanding and defining required services, identifying constraints, and establishing performance - Feasibility study: is it doable? Cost-effective? Market timing appropriate? - 'What' does the system need to do and 'how well'? - Technical, performance, business, cost, schedule, technology, application domain ⚫ Requirements elicitation and analysis derives requirements based on an existing system, customer input, marketing information, and other sources - May involve developing prototypes, system models ⚫ Requirements specification creates written formal 'requirements specification'- To establish 'functional baseline' of system - Note: Today's software tools/approach with customers may drive requirements represented in tools rather than a 'document' ⚫ Requirements 'verification' checks requirement specification for correctness, completeness, consistency, accuracy, preciseness - Checks the specification (did we build the system right?) ⚫ Requirements 'validation' checks requirements with customer for realism, consistency, completeness, errors, fitness for use- Will solve customer's problem (did we build the right system for the customer?)

Other names for Software Process Models

SDLC (Software Development Life Cycle)

What are software products nowadays usually developed with business systems?

Software products are now always developed using an incremental process model. Business systems are increasingly being developed by configuring existing systems and integrating these to create a new system with the functionality that is required.

What is Software Specification?

Software specification or requirements engineering is the process of understanding and defining what services are required from the system and identifying the constraints on the system's operation and development. Requirements engineering is a particularly critical stage of the software process, as mistakes made at this stage inevitably lead to later problems in the system design and implementation.

Test Driven Development

Test-driven development, which is a normal part of agile processes, tests are developed along with the requirements before development starts. This helps the testers and developers to understand the requirements and ensures that there are no delays as test cases are created.

What are the general activities of the design process?

The activities in the design process vary, depending on the type of system being developed. However, the general activities are: 1. Architectural design: where you identify the overall structure of the system, the principal components (sometimes called subsystems or modules), their relationships, and how they are distributed. 2. Database design: where you design the system data structures and how these are to be represented in a database. Again, the work here depends on whether an existing database is to be reused or a new database is to be created. 3. Interface design: where you define the interfaces between system components. This interface specification must be unambiguous. With a precise interface, a component may be used by other components without them having to know how it is implemented. Once interface specifications are agreed, the components can be separately designed and developed. 4. Component selection and design: where you search for reusable components and, if no suitable components are available, design new software components. The design at this stage may be a simple component description with the implementation details left to the programmer. Alternatively, it may be a list of changes to be made to a reusable component or a detailed design model expressed in the UML. The design model may then be used to automatically generate an implementation.

Software specification

The functionality of the software and constraints on its operation must be defined. (requirements)

Software validation

The software must be validated to ensure that it does what the customer wants. Testing the software to see if everything works / Q&A

When the waterfall model is not the right process model

The waterfall model is not the right process model in situations where informal team communication is possible and software requirements change quickly. Iterative development and agile methods are better for these systems

Evolutionary Development Types

There are two types of evolutionary development: -Exploratory development *Start with requirements that are well-defined *Add new features when customers propose new requirements -Throw-away prototyping -Objective is to understand customer's requirements *Customers often don't know what they want, hence poor or incomplete requirements at project start -Used to focus on poorly understood requirements first, then redefine/refine requirements as you progress

How is the incremental development organized

They are interleaved

Integration and configuration

This approach relies on the availability of reusable components or systems. The system development process focuses on configuring these components for use in a new setting and integrating them into a system.

RUP - Universal process model

Various attempts have been made to develop "universal" process models that draw on all of these general models. One of the best known of these universal models is the Rational Unified Process (RUP) (Krutchen 2003), which was developed by Rational, a U.S. software engineering company. The RUP is a flexible model that can be instantiated in different ways to create processes that resemble any of the general process models discussed here. The RUP has been adopted by some large software companies (notably IBM), but it has not gained widespread acceptance.

Definitions

Verification - test the activity of the software that the software meets specification Validation - test the activity that the software meets the needs and expectation of the customer *"Checks that we have the right requirements"

is process improvement built into the agile process?

Yes, it is built in automatically

Agile processes

incremental and it is easier to change the process to reflect changing customer requirements- 'Light-weight' process models. Everyone can work at any part of the stages at a time.

Plan-driven processes

processes where all of the process activities are planned in advance and progress is measured against the plan

Is there an exception of real-time systems?

real-time systems require an additional stage of timing design but may not include a database, so there is no database design involved.

Key Points from Chapter 2

■ Requirements engineering is the process of developing a software specification. Specifications are intended to communicate the system needs of the customer to the system developers. ■ 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. Changes are continuous, and the software must evolve to remain useful. ■ Processes should include activities to cope with change. This may involve a prototyping phase that helps avoid poor decisions on requirements and design. Processes may be structured for iterative development and delivery so that changes may be made without disrupting the system as a whole. ■ Process improvement is the process of improving existing software processes to improve software quality, lower development costs, or reduce development time. It is a cyclic process involving process measurement, analysis, and change.

Software Validation Activities

⚫ 'Verification' and 'validation' (V & V) is intended to show that a system conforms to its specification and meets the needs of the system customer - Verification - did we build the system right? - Validation - did we build the right system? ⚫ V & V involves checking and reviewing processes and system testing ⚫ System testing involves executing the system with test cases that are derived from the specification of the real data expected to be processed by the system during operations ⚫ Testing is the most commonly used V & V activity - Unit testing - Module testing - Sub-system testing - System testing - Acceptance testing

Change

⚫ Anticipate that changes are needed- Do we contract for a duplicate or reduced system in-house to prototype and deliver new changes? $$ - Do we use simulations of the system to develop changes? - Do we develop changes in house and incrementally introduce them to the running system? Small and frequent releases or occasional updates? - Can we update and test the new changes while the users are using the system? Can we backup in case an update goes wrong?

Software Design & Implementation Activities

⚫ Architectural design (the big picture), where you identify the overall structure of the system, the principal components (subsystems or modules), their relationships, and how they are distributed - Components, Connectors, and Constraints (Big 3 C's) ⚫ Database design, where you design the system data structures and how these are represented in a database ⚫ Interface design, where you define the interfaces between system components ⚫ Component selection and design, where you search for reusable components. - If reusable components are unavailable, you design how the components will operate

Process Improvement

⚫ Better, stronger, faster, cheaper!!!- Processes must be measured to be improved ⚫ There are a couple approaches to process improvement- Process Maturity ⚫ Measures process performance maturity against a standard and then select specific improvements to increase maturity- Agile ⚫ Assess process, identify weaknesses in process, develop changes to address specific weaknesses, introduce change incrementally into next process iteration- We will talk about agile processes in the next chapter

Software Maintenance

⚫ Book Author prefers to consider software development a continuum of activity - Initial development and Deployment - Operations & Maintenance - Retirement ⚫ Software maintenance is not the dull, boring, uninteresting activity of maintaining software during operations - Evolution of software - Much of software development work these days is maintenance - "Software that is used, is changed!"

Stages of Testing during Software Validation

⚫ Component Testing - Unit, Module, and Sub-system testing - Individual components are tested independently- Components may be functions or objects or coherent groupings of these entities ⚫ System testing - Incremental build-up of system, testing until entire system is assembled for test - Testing that whole system meets requirements (Verification) - Testing of emergent system properties is particularly important ⚫ Acceptance/Customer testing (can be contractual requirement) - Verifying all requirements are implemented (Verification) - Testing with customer data and witness to check that the system meets the customer's needs (Validation) - Customer evaluation and test in the field -Rather than with simulated test data. For custom-built software, customer testing may reveal errors and omissions in the system requirements definition, because the real data exercise the system in different ways from the test data. Customer testing may also reveal requirements problems where the system's facilities do not really meet the users' needs or the system performance is unacceptable. For products, customer testing shows how well the software product meets the customer's needs.

Change

⚫ Incremental Development - System increments are delivered to the customer for comment and experimentation ⚫ Later release installs agreed-to changes This supports both change avoidance and change tolerance ⚫ Issues - Customers have to stop 'real work' to evaluate changes- Some changes are not needed by customer but may be needed by developer ⚫ Who pays? - Some changes may make things worse!! ⚫ Ouch. Back them out . . . Wasted time? - Change or maintenance contracts rather than a procurement contract ⚫ Plan for change! (Future work)

Capability Maturity Model (CMM)

⚫ Initial level: software development is ad-hoc (default) ⚫ Repeatable level: basic processes are in place ⚫ Defined level: there are organizational level 'standard' processes ⚫ Quantitatively managed level: data is gathered and analyzed routinely ⚫ Optimizing level: stable base performance; data is gathered to measure and improve the process continuously

Process Improvement Involves . . .

⚫ Process measurement - Measure one or more attributes of software process or product - Measurements form baseline that helps decide if process improvements are needed or have been effective ⚫ Process analysis - Current process is assessed and process weaknesses and bottlenecks are identified - Process models (sometimes called process maps) that describe the process activities may be developed, usually collaboratively ⚫ Process change - Process changes are proposed to address some of the identified process weaknesses - These changes are reviewed, approved, and introduced and then the cycle repeats to collect data about the effectiveness of the changes (see process measurement above)

Change

⚫ Prototyping- Version of the system or part of the system is developed quickly to check the customer's requirements and feasibility of design decisions ⚫ Used during requirements engineering process to check feasibility ⚫ Used during design to try out possible design solutions- Prototyping process (Plan - Define - Develop - Evaluate) ⚫ Plan for change!

Software Design & Implementation Activities

⚫ Software is implemented either by developing a program or programs or by configuring an application system ⚫ Design and implementation are interleaved activities for most types of software system - See pic (chapter 2 slide 30) ⚫ Programming is an individual activity with no standard process - Encourage personal software process ⚫ Debugging is the activity of finding program faults and correcting these faults- Usually involves a process: test, fix, repeat

Summary and Wrap-up

⚫ Software processes are composed of activities in a sequence organized in phases to produce software - Abstract representation of activities ⚫ General process models are waterfall, incremental, evolutionary, spiral, agile ⚫ Software processes involve specification, design, implementation, and V & V ⚫ Software evolution or maintenance is process of keeping system relevant with changing business requirements/needs ⚫ Processes should include activities to cope with change- Change is inevitable and persistent ⚫ Processes should be improved

Change is inevitable

⚫ Your new system is built, delivered, working, and making $ for your customer ⚫ Fixing bugs is 'rework', which means to do the work again ⚫ Customer's business model changes . . . - Delivered system must be changed . . . ⚫ New requirements ⚫ New work ⚫ Usually customer needs system to keep working while new requirements are being worked