SOFTWARE ENGINEERING TEST

Agile methods

Focus on the code rather than the design Are based on an iterative approach to software development Are intended to deliver working software quickly and evolve this quickly to meet changing requirements.

What are the attributes of good software?

Good software should deliver the required functionality and performance to the user and should be maintainable, dependable and usable.

Elicitation and analysis

Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system's operational constraints.

Problems with agile methods

It can be difficult to keep the interest of customers who are involved in the process. Team members may be unsuited to the intense involvement that characterizes agile methods. Prioritizing changes can be difficult where there are multiple stakeholders. Maintaining simplicity requires extra work. Contracts may be a problem as with other approaches to iterative development.

Examples of prototyping

LYMB LYMB is an object-oriented development environment aimed at developing applications that require combining graphics-based user interfaces, visualization, and rapid prototyping. PSDL PSDL is a prototype description language, to describe the real-time software

There are separate identified phases in the waterfall model

Requirements analysis and definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance

Requirements scenarios

The customer chooses the stories for inclusion in the next release based on their priorities and the schedule estimates. These are written on cards and the development team break them down into implementation tasks.

There are three phases in Scrum.

The initial phase is an outline planning phase where you establish the general objectives for the project and design the software architecture. This is followed by a series of sprint cycles, where each cycle develops an increment of the system. The project closure phase wraps up the project, completes required documentation such as system help frames and user manuals and assesses the lessons learned from the project.

What are the problems with the traditional methods?

Unclear/Fuzzy Requirements Cannot accommodate changes quickly Heavy Documentation and Sign offs User involvement only at the beginning and end Working software visible very late Testing is (very) late in the project

Types of UML Diagrams

Use Case Diagram: capture requirements. Clarify exactly what the system is supposed to do Displays the relationship among actors and use cases. Different from traditional flow chart. Class Diagram: static relationships between classes. Describe the types of objects in the system and various kinds of static relationships that exist among them. Sequence Diagram: Displays the time sequence of the objects participating in the interaction. Collaboration Diagram Displays an interaction organized around the objects and their links to one another. State Diagram Displays the sequences of states that an object of an interaction goes through during its life in response to received stimuli, together with its responses and actions. Component Diagram Illustrate the organizations and dependencies of the physical components in a system. A higher level than class diagrams.

Types of Requirements

User requirements Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers System requirements A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor Software specification A detailed software description which can serve as a basis for a design or implementation. Written for developers

Requirements checking

Validity Consistency Completeness Realism Verifiability

What are the best software engineering techniques and methods?

While all software projects have to be professionally managed and developed, different techniques are appropriate for different types of system. For example, games should always be developed using a series of prototypes whereas safety critical control systems require a complete and analyzable specification to be developed. You can't, therefore, say that one method is better than another.

The main drawback of the waterfall model

is the difficulty of accommodating change after the process is underway. In principle, a phase has to be completed before moving onto the next phase.

The four basic process activities

specification, development, validation and evolution are organized differently in different development processes.

The most important innovation in the RUP are

the separation of phases and workflows, and the recognition that deploying software in a user's environment is part of the process.

Design activities

-Architectural design, where you identify the overall structure of the system, the principal components (sometimes called sub-systems or modules), their relationships and how they are distributed. -Interface design, where you define the interfaces between system components. -Component design, where you take each system component and design how it will operate. -Database design, where you design the system data structures and how these are to be represented in a database.

Testing stages

-Development or component testing Individual components are tested independently; Components may be functions or objects or coherent groupings of these entities. -System testing Testing of the system as a whole. Testing of emergent properties is particularly important. -Acceptance testing Testing with customer data to check that the system meets the customer's needs.

The process of establishing what services are required and the constraints on the system's operation and development.

-Feasibility study -Requirements elicitation and analysis -Requirements specification -Requirements validation

Waterfall model problems

-Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements. -The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites.

Incremental development benefits

-The cost of accommodating changing customer requirements is reduced. -It is easier to get customer feedback on the development work that has been done. -More rapid delivery and deployment of useful software to the customer is possible.

Incremental development problems

-The process is not visible. -System structure tends to degrade as new increments are added.

The Rational Unified Process

A modern generic process derived from the work on the UML and the associated Unified Software Development Process. +Good example of a hybrid process model. -Brings together aspects of the 3 generic process models discussed previously. -Illustrates good practice in specification and design -Supports prototyping and incremental delivery +Normally described from 3 perspectives -A dynamic perspective that shows phases over time; -A static perspective that shows process activities; -A practice perspective that suggests good practice.

What is a "problem"?

A problem is a difference between things as desired and things as perceived

Feasibility studies

A short focused study that checks -If the system contributes to organisational objectives =If the system can be engineered using current technology and within budget -If the system can be integrated with other systems that are used

Use Case Diagram(core components)

Actors: A role that a user plays with respect to the system,including human users and other systems. e.g.,inanimate physical objects (e.g. robot); an external system that needs some information from the current system. Use case: A set of scenarios that describing an interaction between a user and a system. System boundary: a rectangle diagram representing the boundary between the actors and the system. Association: communication between an actor and a use case; represented by a solid line. Generalization: relationship between one general use case and one specific use case. Represented by a line with a triangular arrow head toward the parent use case, the more general modeling element. Include: a dotted line labeled <<include>> beginning at base use case and ending with an arrows pointing to the include use case. An "Include" relationship is used to indicate that a particular Use Case must include another use case to perform its function Extend: a dotted line labeled <<extend>> with an arrow toward the base case. The extending use case may add behavior to the base use case. The base class declares "extension points".

How large is the system that is being developed?

Agile methods are most effective when the system can be developed with a small co-located team who can communicate informally. This may not be possible for large systems that require larger development teams so a plan-driven approach may have to be used.

Interactive transaction-based applications

Applications that execute on a remote computer and are accessed by users from their own PCs or terminals. These include web applications such as e-commerce applications.

UML: Unified Modeling Language

An industry-standard graphical language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling. The UML uses mostly graphical notations to express the OO analysis and design of software projects. Simplifies the complex process of software design

Software design specification

Client engineers (perhaps) System architects Software developers

User requirements

Client manager System end-users Client engineers Contract managers System architects

Aggregation vs. Composition

Composition is really a strong form of aggregation components have only one owner components cannot exist independent of their owner; both have coincident lifetimes components live or die with their owner e.g. (1)Each car has an engine that can not be shared with other cars. (2) If the polygon is destroyed, so are the points. Aggregations may form "part of" the aggregate, but may not be essential to it. They may also exist independent of the aggregate. Less rigorous than a composition. e.g. (1)Apples may exist independent of the bag. (2)An order is made up of several products, but the products are still there even if an order is cancelled.

What is software?

Computer programs and associated documentation. Software products may be developed for a particular customer or may be developed for a general market.

What is the difference between software engineering and computer science?

Computer science focuses on theory and fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software.

Non-functional requirements

Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.

What are the key challenges facing software engineering?

Coping with increasing diversity, demands for reduced delivery times and developing trustworthy software.

The principles of agile methods

Customer involvement Customers should be closely involved throughout the development process. Their role is provide and prioritize new system requirements and to evaluate the iterations of the system. Incremental delivery The software is developed in increments with the customer specifying the requirements to be included in each increment. People not process The skills of the development team should be recognized and exploited. Team members should be left to develop their own ways of working without prescriptive processes. Embrace change Expect the system requirements to change and so design the system to accommodate these changes Maintain simplicity Focus on simplicity in both the software being developed and in the development process. Wherever possible, actively work to eliminate complexity from the system.

Incremental delivery

Deploy an increment for use by end-users; More realistic evaluation about practical use of software; Difficult to implement for replacement systems as increments have less functionality than the system being replaced

Incremental development

Develop the system in increments and evaluate each increment before proceeding to the development of the next increment; Normal approach used in agile methods; Evaluation done by user/customer proxy.

Code Smells

Duplicate code Long methods Big classes Big switch statements Long navigations (e.g., a.b().c().d()) Lots of checking for null objects Data classes (classes that have mainly fields/properties and little or no methods) Un-encapsulated fields (public member variables)

Class Diagram

Each class is represented by a rectangle subdivided into three compartments Name Attributes Operations Modifiers are used to indicate visibility of attributes and operations. '+' is used to denote Public visibility (everyone) '#' is used to denote Protected visibility (friends and derived) '-' is used to denote Private visibility (no one) By default, attributes are hidden and operations are visible. The last two compartments may be omitted to simplify the class diagrams

What is the main difference between the "Spiral model" and other Software process models?

Explicit Recognition of Risk

Is an incremental delivery strategy, where you deliver the software to customers and get rapid feedback from them, realistic?

If so, consider using agile methods.

Is it important to have a very detailed specification and design before moving to implementation?

If so, you probably need to use a plan-driven approach

Benefits of prototyping

Improved system usability. A closer match to users' real needs. Improved design quality. Improved maintainability. Reduced development effort.

RUP iteration

In-phase iteration Each phase is iterative with the results developed incrementally. Cross-phase iteration As shown by the loop in the RUP model, the whole set of phases may be enacted incrementally.

RUP phases

Inception Establish the business case for the system. Elaboration Develop an understanding of the problem domain Establish an architectural framework Develop the project plan Identify key project risks. Construction System design, programming and testing. Transition Deploy the system in its operating environment.

XP testing difficulties

Incomplete tests Do not check for all possible exceptions that may occur. Some tests can be very difficult to write incrementally. It is difficult to judge the completeness of a set of tests.

XP and agile principles

Incremental development is supported through small, frequent system releases. Customer involvement means full-time customer engagement with the team. People, not process, are supported through pair programming, collective ownership and a process that avoids long working hours. Change supported through regular system releases. Maintaining simplicity through constant refactoring of code.

Extreme programming practices(A)

Incremental planning Requirements are recorded on story cards and the stories to be included in a release are determined by the time available and their relative priority. The developers break these stories into development 'Tasks'. Small releases The minimal useful set of functionality that provides business value is developed first. Releases of the system are frequent and incrementally add functionality to the first release. Simple design Enough design is carried out to meet the current requirements and no more. Test-first development An automated unit test framework is used to write tests for a new piece of functionality before that functionality itself is implemented. Refactoring All developers are expected to refactor the code continuously as soon as possible code improvements are found. This keeps the code simple and maintainable.

Agile manifesto

Individuals and interactions over processes and tools Working software over comprehensive documentation  Customer collaboration over contract negotiation  Responding to change over following a plan

Requirements Document Structure

Introduction Glossary User requirements definition System architecture System requirements specification System models System evolution Appendices Index

Ounce of Prevention

Involve end users as early as possible. Create a throwaway prototyping. Deliver the software incrementally instead of all at once. Conduct a requirements workshop Perform use case analysis Create the user manual first.

Incremental delivery problems

Most systems require a set of basic facilities that are used by different parts of the system. The essence of iterative processes is that the specification is developed in conjunction with the software. Iterative delivery is problematic when the new system is intended to replace an existing system.

Extreme programming

New versions may be built several times per day; Increments are delivered to customers every 2 weeks; All tests must be run for every build and the build is only accepted if tests run successfully.

Spiral model sectors

Objective setting Specific objectives for the phase are identified. Risk assessment and reduction Risks are assessed and activities put in place to reduce the key risks. Development and validation A development model for the system is chosen which can be any of the generic models. Planning The project is reviewed and the next phase of the spiral is planned.

The Sprint cycle

Once these are agreed, the team organize themselves to develop the software. During this stage the team is isolated from the customer and the organization, with all communications channelled through the so-called 'Scrum master'. The role of the Scrum master is to protect the development team from external distractions. At the end of the sprint, the work done is reviewed and presented to stakeholders. The next sprint cycle then begins.

Extreme programming practices (b)

Pair programming Developers work in pairs, checking each other's work and providing the support to always do a good job. Collective ownership The pairs of developers work on all areas of the system, so that no islands of expertise develop and all the developers take responsibility for all of the code. Anyone can change anything. Continuous integration As soon as the work on a task is complete, it is integrated into the whole system. After any such integration, all the unit tests in the system must pass. Sustainable pace Large amounts of overtime are not considered acceptable as the net effect is often to reduce code quality and medium term productivity On-site customer A representative of the end-user of the system (the customer) should be available full time for the use of the XP team. In an extreme programming process, the customer is a member of the development team and is responsible for bringing system requirements to the team for implementation.

Plan-driven and agile development

Plan-driven development A plan-driven approach to software engineering is based around separate development stages with the outputs to be produced at each of these stages planned in advance. Not necessarily waterfall model - plan-driven, incremental development is possible Iteration occurs within activities. Agile development Specification, design, implementation and testing are inter-leaved and the outputs from the development process are decided through a process of negotiation during the software development process.

Boehm's spiral model

Process is represented as a spiral rather than a sequence of activities with backtracking. Each loop in the spiral represents a phase in the process. No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required. Risks are explicitly assessed and resolved throughout the process.

RE defects cost

RE defects cost 10-200 times more to correct once fielded than they would if they were detected during requirements development.

Examples of refactoring

Re-organization of a class hierarchy to remove duplicate code. Tidying up and renaming attributes and methods to make them easier to understand. The replacement of inline code with calls to methods that have been included in a program library.

What are the costs of software engineering?

Roughly 60% of software costs are development costs, 40% are testing costs. For custom software, evolution costs often exceed development costs.

What is software engineering?

Software engineering is an engineering discipline that is concerned with all aspects of software production.

Software evolution

Software is inherently flexible and can change. As requirements change through changing business circumstances, the software that supports the business must also evolve and change. Although there has been a demarcation between development and evolution (maintenance) this is increasingly irrelevant as fewer and fewer systems are completely new.

Acceptability

Software must be acceptable to the type of users for which it is designed. This means that it must be understandable, usable and compatible with other systems that they use.

What are the fundamental software engineering activities?

Software specification, software development, software validation and software evolution.

Customized products

Software that is commissioned by a specific customer to meet their own needs. •Examples -embedded control systems, air traffic control software, traffic monitoring systems.

Generic products

Stand-alone systems that are marketed and sold to any customer who wishes to buy them •Examples•PC software such as graphics programs•Project management tools•CAD software•Software for specific markets such as appointments systems for dentists.

Functional requirements

Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.

System requirements

System end-users Client engineers System architects Software developers

What is the difference between software engineering and system engineering?

System engineering is concerned with all aspects of computer-based systems development including hardware, software and process engineering. Software engineering is part of this more general process.

Stand-alone applications

These are application systems that run on a local computer, such as a PC. They include all necessary functionality and do not need to be connected to a network.

Batch processing systems

These are business systems that are designed to process data in large batches. They process large numbers of individual inputs to create corresponding outputs.

Embedded control systems

These are software control systems that control and manage hardware devices. Numerically, there are probably more embedded systems than any other type of system.

Systems of systems

These are systems that are composed of a number of other software systems.

Systems for modelling and simulation

These are systems that are developed by scientists and engineers to model physical processes or situations, which include many, separate, interacting objects.

Entertainment systems

These are systems that are primarily for personal use and which are intended to entertain the user.

Data collection systems

These are systems that collect data from their environment using a set of sensors and send that data to other systems for processing.

What is a "requirement"?

a condition or capability needed by a user to solve a problem or achieve an objective

The Scrum approach is

a general agile method but its focus is on managing iterative development rather than specific agile practices.

The Rational Unified Process is

a modern generic process model that is organized into phases (inception, elaboration, construction and transition) but separates activities (requirements, analysis and design, etc.) from these phases.

Requirements Engineering (RE)

a set of activities concerned with identifying and communicating the purpose of a software-intensive system, and the contexts in which it will be used. Hence, RE acts as the bridge between the real world needs of users, customers, and other constituencies affected by a software system and the capabilities and opportunities afforded by software- intensive technologies

A software process model is

an abstract representation of a process. It presents a description of a process from some particular perspective.

A prototype is

an initial version of a system used to demonstrate concepts and try out design options.

Change leads to

rework so the costs of change include both rework (e.g. re-analysing requirements) as well as the costs of implementing new functionality

The aim of agile methods is

to reduce overheads in the software process (e.g. by limiting documentation) and to be able to respond quickly to changing requirements without excessive rework.

Verification and validation (V & V) is intended

to show that a system conforms to its specification and meets the requirements of the system customer.

Change tolerance

where the process is designed so that changes can be accommodated at relatively low cost.

Change avoidance

where the software process includes activities that can anticipate possible changes before significant rework is required.