Software Engineering

Sprint

A development iteration. Sprints are usually 2 to 4 weeks long.

Scrum

A daily meeting of the Scrum team that reviews progress and prioritizes work to be done that day. Ideally, this should be a short face-to-face meeting that includes the whole team.

Simple Design

Enough design is carried out to meet the current requirements and no more.

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.

Consistency checks

Requirements in the document should not conflict. That is, there should not be contradictory constraints or different description of the same system function.

Test-case generation

Requirements should be testable. If the tests for the requirements are devised as a part of the validation process, this often reveals requirements problems. If a test is difficult or impossible to design, this usually means that the requirements will be difficult to implement and should be reconsidered. Developing tests from the user requirements before any code is written is an integral part of test-driven development.

Product requirements

Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc.

What are the costs of software engineering?

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

Scrum Agile Method - 8 terms

Scrum is developed to manage the agile process 1. Development team 2. Potentially shippable product increment 3. Product Backlog 4. Product owner 5. Scrum 6. ScrumMaster 7. Sprint 8. Velocity

Index

Several indexes to the document may be included. As well as normal alphabetic index, there may be an index of diagrams, an index of functions, etc.

Requirements reviews

• Regular reviews should be held while the requirements definition is being formulated. • Both client and contractor staff should be involved in reviews. • Reviews may be formal (with completed documents) or informal. Good communications between developers, customers and users can resolve problems at an early stage.

Validity checks

These check that the requirements reflect the real needs of system users. Because of changing circumstances, the user requirements may have changed since they were originally elicited.

Functional Requirements

these are statements of services the system should provide, how the system should react to particular inputs, and how the system should behave in particular situations. In some cases, the functional requirements may also explicitly state what the system should not do.

Metrics for specifying nonfunctional requirements

- Speed - Size - Ease of use - Reliability - Robustness - Portability

The structure of a requirements document

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

Requirements validation techniques

- Requirements Reviews - Prototyping - Test-Case Generation

Requirements engineering process

- Requirements elicitation - Requirements analysis - Requirements validation - Requirements management

Four Product characteristics of software

1. Acceptability - software should be usable, understandable, and compatible with customer's hardware. 2. Dependability and security - reliability, security, and safety - should be safe in the event of system failure - prevents data breaches. 3. Efficiency - Software should not make wasteful use of system resources such as memory and processor cycles - responsiveness, processing time, resource utilization 4. Maintainability - software should be written so it can evolve to meet the changing needs of customers.

Four aspects of software design and implementation

1. Architectural design - identify the overall structure of the system, the principal components, their relationships, and how they are distributed. 2. Database design the process where you design the system data structures and how these are to be represented in a database. 3. Interface design - where we define the interfaces between system components. 4. Component selection and design - we search for reusable components or design new software components.

Coping with change

1. Change anticipation - a prototype system may be developed to show some key features of the system to customers. 2. Change tolerance - process and software are designed so changes can be easily made to the system. Achieved through system prototyping and incremental delivery.

Agile Development Practice

1. Collective Ownership 2. Continuous integration 3. Incremental planning 4. On-site customer 5. Pair Programming 6. Refactoring 7. Simple design 8. Small releases 9. Sustainable pace 10. Test first development

Three components of Software validation

1. Component testing - each of the components making up the system is independently tested. JUnit for Java for example. 2. System testing - system components are integrated to create a complete system. Errors are discovered from interactions between components as well as component interface problems. 3. Customer Testing

Software Engineering Ethics

1. Confidentiality - respect the confidentiality of both employers and clients regardless of contract. 2. Competence - don't misrepresent your level of competence. 3. Intellectual property rights - be aware of laws for intellectual property. 4. Computer misuse - shouldn't misuse other people's computers for gaming or viruses.

Agile Principles and Organizational Practice

1. Customer Involvement 2. Embrace change 3. Incremental Delivery 4. Maintain simplicity 5. People, not process

Principles of Agile Development

1. Customer involvement 2. Embrace Change 3. Incremental Delivery 4. Mantain simplicity 5. People, not process

The Waterfall Model

1. Define requirements - systems services, constrains and goals must be established through consultation with a system's 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 describin gthe fundamental software systems abstractions and their relationships. 3. Implementation and unit testing - during this stage, the software design is realized as a set of programs or program units. Unit testing involves verifying that each unit meets its specification. 4. Integration and system testing - the individual program units are integrated and tested as a complete system to ensure that the software requirements have been met. After testing, the software systems is delivered to the customer. 5. Operation and maintenance - involves correcting errors, improving implementation of system units, and enhancing the system's services as new requirements are discovered.

What systems is the waterfall model appropriate for?

1. Embedded systems 2. Critical systems in which there is a need for extensive safety and security analysis for software specification and design. 3. Large software systems the are part of broader engineering systems developed by several companies.

What are the two different kinds of software products?

1. Generic products - apps for mobile devices, software for PC's such as word processors, etc. 2. Customized (bespoke) software - control systems for electronic devices, systems are written to support a particular business process, and air traffic control systems.

Reliability

1. Mean time to failure 2. Probability of unavailability 3. Rate of failure occurrence 4. Availability

Types of non-functional requirements

1. Product Requirements 2. Organizational Requirements 3. External requirements

Processes of the requirements engineering process.

1. Requirements elicitation and analysis - the process of deriving the system requirements through observation of existing systems. 2. Requirements specification - the activity of translating the information gathered during requirements analysis into a document that defines a set of requirements. 3. Requirements validation - checks the requirements for realism, consistency, and completeness.

General process model for reuse based development

1. Requirements specification 2. Software discovery and evaluation - a search is made for components and systems that provide the functionality required 3. Requirements refinement - requirements are refined using information about the reusable components and applications that have been discovered. 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 systems. 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.

Impact of the internet on software engineering

1. Software reuse was become a dominant approach 2. Incremental development 3. Service-oriented software engineering where software components are stand-alone web services. 4. Interface development technology such as HTML5 support the creation of rich interfaces.

Four fundamental software engineering activities

1. Software validation - the functionality of the software and constraints on its operation must be defined 2. Software development - the software must meet the specifications. 3. Software validation - the software must be validated to ensure that it does what the customer wants. 4. Software evolution - the software must evolve to meet changing customer needs.

Software Engineering Diversity - 8 categories

1. Stand Alone applications - CAD programs, office applications, photo editing software. 2. Interactive transaction-based applications - amazon, facebook market, grubhub, etc. 3. Embedded control systems - software control systems that control and manage hardware devices - software in a microwave oven to control the cooking process, software to stabilize a submarine. 4. Batch processing systems - periodic billing systems, salary payment systems 5. Entertainment systems - consoles, video games 6. Systems for modeling and simulation - systems developed for scientist and engineers to model physical processes 7. Data collection and analysis systems - data mining - big data analysis involves cloud-based systems that carry out statistical analysis and look for relationships in the collected data. 8. Systems of systems - servers that provide clients for employees

Practical Problems with agile methods

1. The informality of agile development is incompatible with the legal approach to contract definition that is commonly used in large companies. 2. Agile methods are most appropriate for new software development rather than software maintenance. Yet the majority of software costs in large companies come from maintaining their existing software systems. 3. Agile methods are designed for small co-located teams yet much software development now involves worldwide distributed teams.

Software Process Models

1. The waterfall model - requirement specification, software design, implementation, and testing. 2. Incremental development - interleaves the activities of specification, development, and validation. The system is developed through a series of versions. 3. Integration and configuration - 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.

Requirements Validation checks

1. Validity checks 2. Consistency checks 3. Completeness checks 4. Realism checks 5. Verifiability

ScrumMaster

A person who ensures that the team is productive, facilitates the daily Scrum, enables close cooperation across all roles and functions, and removes barriers that prevent the team from being effective

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.

Development team

A self-organizing group of software developer, which should be no more than seven people. They are responsible for developing the software and other essential project documents

Advantages and Disadvantages of Incremental Programming

Advantages - less documentation and analysis needs to be redone, easier to get customer feedback, early development and deployment of software is possible. Disadvantages - the software development process is invisible, and the system structure tends to degrade as new increments are added.

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.

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.

Velocity

An estimate of how much product backlog effort a team can cover in a single sprint. Understanding a team's velocity helps them estimate what can be covered in a sprint and provides a basis for measuring improving performance.

Product Owner

An individual (or possibly a small group) whose job is to identify product features or requirements, prioritize these for development and continuously review the product backlog to ensure that the project continues to meet critical business needs. The Product Owner can be a customer but might also be a product manager in a software company or other stakeholder representative.

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.

Realism checks

By using knowledge of existing technologies, the requirements should be checked to ensure that they can be implemented within the proposed budget for the system. These checks should also take account of the budget and schedule for the system development.

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.

What are the key challenges facing software engineering?

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

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.

Pair Programming

Developers work in pairs, checking each other's work and providing the support to always do a good job.

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.

User requirements definintion

Here, you describe the services provided for the user. The nonfunctional system requirements should also be described in this section. This description may use natural language, diagrams, or other notations that are understandable to customers. Product and process standards that must be followed should be specified.

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

People, not process (organization)

Individual team members may not have suitable personalities for the intense involvement that is typical of agile methods and therefore may not interact well with other team members.

Sustainable pace

Large amounts of overtime are not considered acceptable as the net effect is often to reduce code quality and medium term productivity

Size

Megabytes/number of ROM chips

What differences has the internet made to software engineering?

Not only has the internet led to the development of massive, highly distributed, service based systems, it has also supported the creation of an app industry for mobile devices which has changed the economics of software.

Embrace change

Prioritizing changes can be extremely difficult, especially in systems for which there are many stakeholders. Typically, each stakeholder gives different priorities to different changes.

Speed

Processed transactions/second User/event response time Screen refresh time

Incremental delivery

Rapid iterations and short-term planning for development does not always fit in with the longer-term planning cycles of business planning and marketing. Marketing managers may need to know product features several months in advance to prepare an effective marketing campaign.

What is software engineering?

Software engineering is an engineering discipline that is concerned with all aspects of software production from initial conception to operation and maintenance.

What are the fundamental software engineering activities?

Software specification , software development, software validation and software evolution

Ease of use

Training time Number of help frames

Requirements change

Some requirements are often not clearly defined and understood until later. When a changed understanding of a problem is achieved, there is a change in the requirements that can be addressed.

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.

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.

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.

Requirements specification

The process of writing down the user and system requirements in a requirements document

Completeness checks

The requirements document should include requirements that define all functions and the constraints intended by the system user.

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.

Potentially Shippable Product Increment

The software increment that is delivered from a sprint. The idea is that this should be 'potentially shippable' which means that it is in a finished state and no further work, such as testing, is needed to incorporate it into the final product. In practice, this is not always achievable.

Incremental Delivery

The software is developed in increments with the customer specifying the requirements to be included in each increment.

Non-functional Requirements

These are constraints on the services or functions offered by the system. They include timing constraints, constraints on the development process, and constraints imposed by standards. Non-functional requirements often apply to the system as a whole rather than individual system features or services.

Appendices

These provide detailed, specific information that is related to the application being developed- for example, hardware and database descriptions. Hardware requirements define the minimal and optimal configurations for the system. Database requirements define the logical organization of the data used by the system and the relationships between data.

Organizational Requirements

These requirements are broad system requirements derived from policies and procedures in the customers and developer's organizations. Examples include operational process requirements that define how the system will be used; development process requirements that specify the programming language, the development environment or process standards to be used; and environmental requirements that specify the operating environment of the system.

System models

This chapter includes graphical system models showing the relationships between the system components and the system and its environment. Examples of possible models are object models, data-flow models, or semantic data models.

System architecture

This chapter presents a high-level overview of the anticipated system architecture, showing the distribution of function across system modules. Architectural components that are reused should be highlighted.

Preface

This defines the expected readership of the document and describes its version history, including a rationale for the creation of a new version and a summary of the changes made in each version.

Glossary

This defines the technical terms used in the document. You should not make assumptions about the experience or expertise of the reader

Customer Involvement

This depends on having a customer who is willing and able to spend time with the development team and who can represent all system stakeholders. Often, customer representatives have other demands on their time and cannot play a full part in the software development. Where there are external stakeholders, such as regulators, it is difficult to represent their views to the agile team.

System requirements specification

This describes the functional and nonfunctional requirements in more detail. If necessary, further detail may also be added to the nonfunctional requirements. Interfaces to other systems may be defined.

System evolution

This describes the fundamental assumptions on which the system is based, and any anticipated changes due to hardware evolution, changing user needs, and so on. This section is useful for system designers as it may help them avoid design decisions that would constrain likely future changes to the system.

Introduction

This describes the need for the system. It should briefly describe the system's functions and explain how it will work with other systems. It should also describe how the system fits into the overall business or strategic objectives of the organization commissioning the software.

Prototyping

This involves developing an executable model of a system and using this with end-users and customers to see if it meets their needs and expectations. Stakeholders experiment with the system and feed back requirements changes to the development team.

Product backlog

This is a list of 'to do' items which the Scrum team must tackle. They may be feature definitions for the software, software requirements, user stories or descriptions of supplementary tasks that are needed, such as architecture definition or user documentation.

Verifiability

To reduce the potential for dispute between customer and contractor, system requirements should always be written so they are verifiable. This means that you should be able to write a set of tests that can demonstrate that the delivered system meets each specified requirement.

Maintain simplicity (organizaton)

Under pressure form delivery schedules, team members may not have time to carry out desirable system simplifications.

What are the best software and engineering techniques and methods

While all software projects have to be professionally managed and developed, different techniques are appropriate for different types of systems. 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. There are no methods and techniques that are good for everything.

Requirements Validation

Work done to evaluate requirements to ensure they support the delivery of the expected benefits and are within the solution scope.

Requirements elicitation

gathering system requirements from various stakeholders through observation and interviews