Software engineering

Architectural design

-how software is organized -²identifies the main structural components in a system and the relationships between them - output is architectural model that describes how the system is organized as a set of communicating components -²It is generally accepted that an early stage of agile processes is to design an overall systems architecture

cost break down of software engineering

60% development 40% testing

Design activities

Architectural design-overall structure Database design - interface design - how parts will interact component selection and design

Architectural abstraction

Architecture in the small - is concerned with the architecture of individual programs. ²Architecture in the large - is concerned with the architecture of complex enterprise systems that include other systems, programs, and program components. These enterprise systems are distributed over different computers, which may be owned and managed by different companies.

Ethics

Confidentiality Competence Intellectual property rights Computer misuse ACM/IEEE code of ethics

Integration and configurations Software process models COTS

The system is assembled from existing configurable components. May be plan-driven or agile. Based on reuse of software from existing components COTS- commercial off the shelf Reused elements may be changed to suit new needs better Steps: ²Requirements specification ²Software discovery and evaluation ²Requirements refinement ²Application system configuration ²Component adaptation and integration Pros and cons: ²Reduced costs and risks as less software is developed from scratch ²Faster delivery and deployment of system ²But requirements compromises are inevitable so system may not meet real needs of users ²Loss of control over evolution of reused system elements

System modeling

abstract models of a system with models showing different view of the system. helps analysts understand the functionality of system Unified Modeling Language (UML)

Use of architectural models

discussion or documentation

Behavioral models

dynamic behavior- how system responds to stimulus 2 types of stimuli: data events

Agile methods

focus on code rather than design use an iterative approach deliver working software quickly -try to reduce overheads in processes (limiting doc) so it can quickly change based on changing requirements

What is good software

maintainable dependable efficiency and acceptability

Model-driven engineering (MDE

models, not programs are the output . programs are then generated from the model. this raises the level of abstraction ²Pros §Allows systems to be considered at higher levels of abstraction §Generating code automatically means that it is cheaper to adapt systems to new platforms. ²Cons §Models for abstraction and not necessarily right for implementation §Savings from generating code may be outweighed by the costs of developing translators for new platforms

Agile methods for large systems

mostly disconnected teams brownfield systems ✧that is they include and interact with a number of existing systems. Many of the system requirements are concerned with this interaction and so they do not really lend themselves to flexibility and incremental development. ✧Where several systems are integrated to create a system, a significant fraction of the development is concerned with system configuration rather than original code development.

Software

not just the programs themselves but also all associated documentation, libraries, support websites, and configuration data that are needed to make these programs useful.

Factors affecting software pricing

see slide pics

Main Differences between Code Coverage and Test Coverage

see slide pics

Object class aggregation models

²An aggregation model shows how classes that are collections are composed of other classes ²Aggregation models are similar to the part-of relationship in semantic data models

Application architectures

²Application systems are designed to meet an organizational need ²As businesses have much in common, their application systems also tend to have a common architecture that reflects the application requirements ²A generic application architecture is an architecture for a type of software system that may be configured and adapted to create a system that meets specific requirements

Risk analysis

²Assess probability and seriousness of each risk ²Probability may be very low, low, moderate, high or very high ²Risk consequences might be catastrophic, serious, tolerable or insignificant

Dependability economics

²Because of very high costs of dependability achievement, it may be more cost effective to accept untrustworthy systems and pay for failure costs ²However, this depends on social and political factors. A reputation for products that cannot be trusted may lose future business ²Depends on system type - for business systems in particular, modest levels of dependability may be adequate

Business value assessment

²Business value assessment should take different viewpoints into account §System end-users §Business customers §IT managers §Senior managers ²Interview different stakeholders and collate results

Class diagrams

²Class diagrams are used when developing an object-oriented system model to show the classes in a system and the associations between these classes ²An object class can be thought of as a general definition of one kind of system object ²An association is a link between classes that indicates that there is some relationship between these classes. ²When you are developing models during the early stages of the software engineering process, objects represent something in the real world, such as a patient, a prescription, doctor, etc.

Software pricing

²Estimates are made to discover the cost, to the developer, of producing a software system. §You take into account, hardware, software, travel, training and effort costs. ²There is not a simple relationship between the development cost and the price charged to the customer. ²Broader organisational, economic, political and business considerations influence the price charged.

Pipe and filter architecture

²Functional transformations process their inputs to produce outputs ²May be referred to as a pipe and filter model (as in UNIX shell) ²Variants of this approach are very common. When transformations are sequential, this is a batch sequential model which is extensively used in data processing systems ²Not really suitable for interactive systems

Information systems architecture

²Information systems have a generic architecture that can be organized as a layered architecture ²These are transaction-based systems as interaction with these systems generally involves database transactions ²Layers include: §The user interface §User communications §Information retrieval System database

Software maintenance

²Maintenance = modifying a program after it has been put into use ²The term is mostly used for changing custom software. Generic software products are said to evolve to create new versions. ²Maintenance does not normally involve major changes to the system's architecture ²Changes are implemented by modifying existing components and adding new components to the system

Maintenance prediction

²Maintenance prediction is concerned with assessing which parts of the system may cause problems and have high maintenance costs §Change acceptance depends on the maintainability of the components affected by the change §Implementing changes degrades the system and reduces its maintainability §Maintenance costs depend on the number of changes and costs of change depend on maintainability

Risk identification

²May be a team activities or based on the individual project manager's experience ²A checklist of common risks may be used to identify risks in a project §Technology risks §Organizational risks §People risks §Requirements risks §Estimation risks

Regression testing

²Regression testing is testing the system to check that changes have not 'broken' previously working code. ²In a manual testing process, regression testing is expensive but, with automated testing, it is simple and straightforward. All tests are rerun every time a change is made to the program. ²Tests must run 'successfully' before the change is committed.

Safety regulation

²Regulation and compliance (following the rules) applies to the sociotechnical system as a whole and not simply the software element of that system ²Safety-related systems may have to be certified as safe by the regulator ²To achieve certification, companies that are developing safety-critical systems have to produce an extensive safety case that shows that rules and regulations have been followed ²It can be as expensive to develop the documentation for certification as it is to develop the system itself ²

Release and iteration planning

²Release planning involves selecting and refining the stories that will reflect the features to be implemented in a release of a system and the order in which the stories should be implemented. ²Stories to be implemented in each iteration are chosen, with the number of stories reflecting the time to deliver an iteration (usually 2 or 3 weeks). ²The team's velocity is used to guide the choice of stories so that they can be delivered within an iteration.

structural models

²Structural models of software display the organization of a system in terms of the components that make up that system and their relationships ²You create structural models of a system when you are discussing and designing the system architecture

System testing

²System testing during development involves integrating components to create a version of the system and then testing the integrated system. ²The focus in system testing is testing the interactions between components. ²System testing checks that components are compatible, interact correctly and transfer the right data at the right time across their interfaces. ²System testing tests the emergent behavior of a system.

Use-case testing

²The use-cases developed to identify system interactions can be used as a basis for system testing. ²Each use case usually involves several system components so testing the use case forces these interactions to occur. ²The sequence diagrams associated with the use case documents the components and interactions that are being tested.

Unit testing

²Unit testing is the process of testing individual components in isolation. ²It is a defect testing process. ²Units may be: §Individual functions or methods within an object §Object classes with several attributes and methods §Composite components with defined interfaces used to access their functionality.

Verification vs validation

²Verification: "Are we building the product right". ²The software should conform to its specification. ²Validation: "Are we building the right product". ²The software should do what the user really requires.

Architectural representations

²block diagrams - showing entities and relationships are the most frequently used method for documenting software architectures, informal very abstract, good for talking to stakeholders

User stories

✧User requirements are expressed as user stories or scenarios ✧These are written on cards and the development team break them down into implementation tasks. These tasks are the basis of schedule and cost estimates. ✧The customer chooses the stories for inclusion in the next release based on their priorities and the schedule estimates ✧As a <type of user>, I want <to perform some task>so that I can <achieve some goal/benefit/value>. ✧As an Amazon Customer, I want to be able to search for a product So that I can purchase the product I need.

Testing stages

Component- individual components tested system- testing whole system testing of emergent properties Customer- using customer data to verify we meet their needs

Incremental Delivery software process model 4

Develop the system in increments and evaluate each increment before proceeding to the development of the next increment §Deploy an increment for use by end-users §Evaluation done by user/customer proxy §Normal approach used in agile methods §More realistic evaluation about practical use of software §Difficult to implement for replacement systems as increments have less functionality than the system being replaced Pros: ²Customer value can be delivered with each increment so system functionality is available earlier ²Early increments act as a prototype to help elicit requirements for later increments ²Lower risk of overall project failure ²The highest priority system services tend to receive the most testing Cons: often need basic functionality that can be hard to define as requirements are no detailed until increment is to be implemented ²The essence of iterative processes is that the specification is developed in conjunction with the software however often conflicts with predocument model many use

Scrum terminology

Development team- self organizing group of less than 8 deves that deve software and other stuff Potentially shippable product increment- output of a sprit, it should need no further work, not always possible Product backlog- to do list Product owner- person or group whos job is to priorities task to get the product done, could be a customer Scrum- daily meeting short with whole team scrumMaster- ensures the process is followed sprint- development iteration Velocity- how much a team can do in a sprit

Program testing

can reveal presence of errors NOT their absence.

Software evolution

change software to meet new circumstances ²Although there has been a demarcation between development and evolution (maintenance) this is increasingly irrelevant as fewer and fewer systems are completely new

principles of agile methods

customer involvement- provide initial and new requirements and evaluate iterations incremental delivery- develop in increments with customer requirements for each people not process - team members left to own without prescriptive processes embrace change- things will change, expect it maintain simplicity- activity work to eliminate complexity from system

XP practices

incremental planning- requirements are recorded on story cards then broken into task small releases- most important things developed first then added onto. simple design- meet current requirements and that's it 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 - deves will refactor continuously as soon as improvements are found pair programming - work in pairs to peer edit collective ownership- everyone works on everything continuous integration - as soon as a task is done integrate it into the system sustainable pace- no large amounts of overtime on-site customer- end-user should be on the team to give feed back and requirements. ✧Key practices ▪User stories for specification ▪Refactoring ▪Test-first development ▪Pair programming

Process improvement inc

process maturity approach - which focuses on improving process and project management and introducing good software engineering practice -good technical and management practice are the foundation agile approach- which focuses on iterative development and the reduction of overheads in the software process -rapid delivery of functionality and responsiveness to changing customer requirements are the foundation

Agile vs scrum

project managers job is the software is delivered on time and within the planned budget ✧Agile is a methodology based on iterative development ✧Scrum is a type of agile approach that is used in software development For your Resume: Familiar with Agile methodologies and worked in a Scrum development environment (or knowledgeable of the Scrum approach) Do Not Put: Familiar with Scrum methodologies

Customer involvement

they will develop acceptance tests for the stories that need to be implemented this iteration

Sprints

2-4 weeks ✧The starting point for planning is the product backlog, which is the list of work to be done on the project ✧The selection phase involves all of the project team who work with the customer to select the features and functionality from the product backlog to be developed during the sprint ✧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 '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.

Scrum

3 phases: ▪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's 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 Pros: project broken down into manageable understandable chunks everyone has visibility of everything customers see on time delivery of products Trust is established between deves and customers

Software project failure

Due to increasing system complexity or failure too use software engineering methods correctly

Formula to calculate Test Coverage

Formula to calculate Test Coverage To calculate test coverage, follow the steps: Step 1: Count the total lines of code in the software you are testing (X) Step 2: Count the total number of lines of code all test cases execute (Y) Step 3: Divide Y by X and multiply by 100. The result is your test coverage in %. Example: If the number of lines of code in a system component is 1000 and the number of lines executed across all existing test cases is 160, then your test coverage is: (160 / 1000) * 100 = 16%

Agile methods and MDA

MDA uses lots of up front documentation in the creating of models ²If transformations can be completely automated and a complete program generated from a PIM, then, in principle, MDA could be used in an agile development process as no separate coding would be required

waterfall Software process models

Plan-driven model. Separate and distinct phases of specification and development. no iterating steps: requirements system and software design implementation and unit testing integration and system, testing operation and maintenance Best used when requirements are well understood and change little most used for large systems as the rigid model helps to coordinate

Scaling agile methods

Scaling up - using agile for large systems that cannot be done by a small team scaling out - how agile can be introduced across a large organization Practical problems: ✧The informality of agile development is incompatible with the legal approach to contract definition that is commonly used in large companies ✧Most cost come from maintenance which agile is not optimal for ✧Not designed for distributed teams

Web based

Should reuse lots of software incremental and agile are best as you cannot specify all requirements in advance

incremental development Software process models

Specification, development and validation are interleaved. May be plan-driven or agile. First we start with and outline of the project then currently we create specification do development and validation creating an initial intermediate and final versions. less doc than waterfall so it is easer to change can get customer feedback on stages of projects customers can use competed parts of software sooner than with waterfall Problems: lack of doc it is no cost effective to make doc for every version of the system Unless refactoring is done changes corrupts the structure of initial code base

Generic products

These are stand-alone systems that are produced by a development organization and sold on the open market to any customer who is able to buy them.

Customized (or bespoke) software

These are systems that are commissioned by and developed for a particular customer.

Types of requirements

User requirements -written and diagrams of the servers of the system, for the customer system requirements -§A structured document setting out detailed descriptions of the system's functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor.

System persepectives

external - model the context or environment interaction - model interactions between system and environment or system components structural- model organization of system or structure of data behavioral- how system responds to events

General issues in software

heterogeneity, business and social change, security adn trust, and scale

Change

leads to rework so cost of change include rework go back to your model as well as cost of new functionality Change anticipation - where the software process includes activities that can anticipate possible changes before significant rework is required. can use System prototyping Change tolerance - design in a way that is low cost to add features, like an incremental delivery of software

Refactoring

look to improve code even when there is no immediate need. ✧This improves the understandability of the software and so reduces the need for documentation ✧Changes are easier to make because the code is well-structured and clear ✧However, some changes require architecture refactoring and this is much more expensive

Requirements validation

making sure the requirements are really what customer wants fixing requirements is costly ²Validity. Does the system provide the functions which best support the customer's needs? ²Consistency. Are there any requirements conflicts? ²Completeness. Are all functions required by the customer included? ²Realism. Can the requirements be implemented given available budget and technology ²Verifiability. Can the requirements be checked?

fundamental principles of software

managed and understood development process. Dependability and performance are important for all types of system software specification and requirements are important reuse software that has already been developed

Layered architecture

model the interfacing of sub-systems ²Organizes the system into a set of layers (or abstract machines) each of which provide a set of services ²Supports the incremental development of sub-systems in different layers. When a layer interface changes, only the adjacent layer is affected. ²However, it is often artificial to structure systems in this way

fundamental software engineering activities

requirements, design, implementations, verification, maintenance

software validation (V and V)

show a system conforms to specs sing test cases

SDLC

software/system Development life cycle is Requirement analysis, design, implementation, testing, evolution then back to requirements

Representing architectural views

some use UML Somerville disagrees

App types

stand-alone apps, interactive transaction-based apps, embedded systems, Batch processing, entertainment, simulation Data collection, and system of systems.

Test-driven development

writing test first makes you understand the requirements better tests are automatic programs all test are run when new functionality is added

Group organization

§Key questions include: •Should the project manager be the technical leader of the group? •Who will be involved in making critical technical decisions, and how will these be made? •How will interactions with external stakeholders and senior company management be handled? •How can groups integrate people who are not co-located? •How can knowledge be shared across the group? ²Small software engineering groups are usually organized informally without a rigid structure ²For large projects, there may be a hierarchical structure where different groups are responsible for different sub-projects ²Agile development is always based around an informal group on the principle that formal structure inhibits information exchange

Types of model

²A computation independent model (CIM) §These model the important domain abstractions used in a system. CIMs are sometimes called domain models. ²A platform independent model (PIM) §These model the operation of the system without reference to its implementation. The PIM is usually described using UML models that show the static system structure and how it responds to external and internal events. ²Platform specific models (PSM) §These are transformations of the platform-independent model with a separate PSM for each application platform. In principle, there may be layers of PSM, with each layer adding some platform-specific detail.

What is a User Story?

²A description of a software feature from an end-user perspective ²It describes who the user is and what they want and why ²A user story helps create a simplified description of a requirement and what it should achieve ² RECOMMENDED FORMAT User stories typically follow a simple template: As a <type of user>, I want <some goal> so that <some reason>.

Project startup planning

²At this stage, you know more about the system requirements but do not have design or implementation information ²Create a plan with enough detail to make decisions about the project budget and staffing. §This plan is the basis for project resource allocation ²The startup plan should also define project monitoring mechanisms ²A startup plan is still needed for agile development to allow resources to be allocated to the project

4 + 1 view model of software architecture

²A logical view, which shows the key abstractions in the system as objects or object classes ²A process view, which shows how, at run-time, the system is composed of interacting processes ²A development (implementation) view, which shows how the software is decomposed for development ²A physical (deployment) view, which shows the system hardware and how software components are distributed across the processors in the system Related using a use case view (+1) •There is a typical "4+1 views" architecture of a system defined by UML: Logical view, captures the vocabulary of the problem domain using classes and objects Process view, depicts the threads and processes of the system as active classes Implementation view, shows the physical code base of the system in terms of components Deployment view, models the physical deployment of components onto computational nodes Use case view, captures the requirements of the system using a set of use cases. This is the view "+1" to which all other views connect.

Prototyping

²A prototype is an initial version of a system used to demonstrate concepts and try out design options pros: ²Improved system usability ²A closer match to users' real needs ²Improved design quality ²Improved maintainability ²Reduced development effort ²May involve leaving out functionality Prototype should focus on areas of the product that are not well-understood Error checking and recovery may not be included in the prototype Focus on functional rather than non-functional requirements such as reliability and security often throw-away - undocumented and not up to quality standards

Automated test components

²A setup part, where you initialize the system with the test case, namely the inputs and expected outputs. ²A call part, where you call the object or method to be tested. ²An assertion part where you compare the result of the call with the expected result. If the assertion evaluates to true, the test has been successful if false, then it has failed.

Software delivery

²A software increment is always delivered at the end of each project iteration. ²If the features to be included in the increment cannot be completed in the time allowed, the scope of the work is reduced. ²The delivery schedule is never extended.

UML types

²Activity diagrams, which show the activities involved in a process or in data processing ²Use case diagrams, which show the interactions between a system and its environment ²Sequence diagrams, which show interactions between actors and the system and between system components ²Class diagrams, which show the object classes in the system and the associations between these classes ²State diagrams, which show how the system reacts to internal and external events Use to facilitate discussion about system or to document or as detailed system description

Problems with redundancy and diversity

²Adding diversity and redundancy to a system increases the system complexity ²This can increase the chances of error because of unanticipated interactions and dependencies between the redundant system components ²Some engineers therefore advocate simplicity and extensive V & V as a more effective route to software dependability ²Airbus FCS architecture is redundant/diverse; Boeing 777 FCS architecture has no software diversity ²

Agile methods and evolution

²Agile methods are based on incremental development so the transition from development to evolution is a seamless one §Evolution is simply a continuation of the development process based on frequent system releases ²Automated regression testing is particularly valuable when changes are made to a system ²Changes may be expressed as additional user stories

Agile planning

²Agile methods of software development are iterative approaches where the software is developed and delivered to customers in increments. ²Unlike plan-driven approaches, the functionality of these increments is not planned in advance but is decided during the development. §The decision on what to include in an increment depends on progress and on the customer's priorities. ²The customer's priorities and requirements change so it makes sense to have a flexible plan that can accommodate these changes.

Agile planning difficulties

²Agile planning is reliant on customer involvement and availability. ²This can be difficult to arrange, as customer representatives sometimes have to prioritize other work and are not available for the planning game. ²Furthermore, some customers may be more familiar with traditional project plans and may find it difficult to engage in an agile planning process.

Agile planning applicability

²Agile planning works well with small, stable development teams that can get together and discuss the stories to be implemented. ²However, where teams are large and/or geographically distributed, or when team membership changes frequently, it is practically impossible for everyone to be involved in the collaborative planning that is essential for agile project management.

Motivating people

²An important role of a manager is to motivate the people working on a project ²Motivation means organizing the work and the working environment to encourage people to work effectively §If people are not motivated, they will not be interested in the work they are doing. They will work slowly, be more likely to make mistakes and will not contribute to the broader goals of the team or the organization. ²Motivation is a complex issue but it appears that their are different types of motivation based on: §Basic needs (e.g. food, sleep, etc.); §Personal needs (e.g. respect, self-esteem); §Social needs (e.g. to be accepted as part of a group). ²

System stake holder

²Any person or organization who is affected by the system in some way and so who has a legitimate interest ²Stakeholder types §End users §System managers §System owners §External stakeholders

Architectural design decisions

²Architectural design is a creative process so the process differs depending on the type of system being developed ²However, a number of common decisions span all design processes and these decisions affect the non-functional characteristics of the system

Use of application architectures

²As a starting point for architectural design ²As a design checklist ²As a way of organizing the work of the development team ²As a means of assessing components for reuse ²As a vocabulary for talking about application types

Need satisfaction

²In software development groups, basic physiological and safety needs are not an issue. ²Social §Provide communal facilities §Allow informal communications, e.g. via social networking ²Esteem §Recognition of achievements §Appropriate rewards ²Self-realization §Training - people want to learn more §Responsibility

Principal properties

²Availability §The probability that the system will be up and running and able to deliver useful services to users ²Reliability §The probability that the system will correctly deliver services as expected by users ²Safety §A judgment of how likely it is that the system will cause damage to people or its environment ²Security §A judgment of how likely it is that the system can resist accidental or deliberate intrusions ²Resilience §A judgment of how well a system can maintain the continuity of its critical services in the presence of disruptive events such as equipment failure and cyberattacks Other properties ²Repairability §Reflects the extent to which the system can be repaired in the event of a failure ²Maintainability §Reflects the extent to which the system can be adapted to new requirements ²Error tolerance §Reflects the extent to which user input errors can be avoided and tolerated

Dependability achievement

²Avoid the introduction of accidental errors when developing the system ²Design V & V processes that are effective in discovering residual errors in the system ²Design systems to be fault tolerant so that they can continue in operation when faults occur ²Design protection mechanisms that guard against external attacks ²Configure the system correctly for its operating environment ²Include system capabilities to recognize and resist cyberattacks ²Include recovery mechanisms to help restore normal system service after a failure ²

System quality assessment

²Business process assessment §How well does the business process support the current goals of the business? ²Environment assessment §How effective is the system's environment and how expensive is it to maintain? ²Application assessment §What is the quality of the application software system?

General testing guidelines

²Choose inputs that force the system to generate all error messages ²Design inputs that cause input buffers to overflow ²Repeat the same input or series of inputs numerous times ²Force invalid outputs to be generated ²Force computation results to be too large or too small.

Factors influencing project management

²Company size ²Software customers ²Software size ²Software type ²Organizational culture ²Software development processes ²These factors mean that project managers in different organizations may work in quite different ways ²

Object class testing

²Complete test coverage of a class involves §Testing all operations associated with an object §Setting and interrogating all object attributes §Exercising the object in all possible states. ²Inheritance makes it more difficult to design object class tests as the information to be tested is not localised.

Software project management

²Concerned with activities involved in ensuring that software is delivered on time and on schedule and in accordance with the requirements of the organizations developing and procuring the software ²Project management is needed because software development is always subject to budget and schedule constraints that are set by the organization developing the software

Risk planning

²Consider each risk and develop a strategy to manage that risk ²Avoidance strategies §The probability that the risk will arise is reduced ²Minimization strategies §The impact of the risk on the project or product will be reduced ²Contingency plans §If the risk arises, contingency plans are plans to deal with that risk

People management factors

²Consistency §Team members should all be treated in a comparable way without favourites or discrimination ²Respect §Different team members have different skills and these differences should be respected ²Inclusion §Involve all team members and make sure that people's views are considered ²Honesty §You should always be honest about what is going well and what is going badly in a project

Context models

²Context models are used to illustrate the operational context of a system - they show what lies outside the system boundaries ²System boundaries are established to define what is inside and what is outside the system-some boundaries may force more work on some part of organization

Examples of application types

²Data processing applications §Data driven applications that process data in batches without explicit user intervention during the processing ²Transaction processing applications §Data-centered applications that process user requests and update information in a system database ²Event processing systems §Applications where system actions depend on interpreting events from the system's environment ²Language processing systems §Applications where the users' intentions are specified in a formal language that is processed and interpreted by the system

Data driven modeling

²Data-driven models show the sequence of actions involved in processing input data and generating an associated output ²They are particularly useful during the analysis of requirements as they can be used to show end-to-end processing in a system

Success criteria

²Deliver the software to the customer at the agreed time ²Keep overall costs within budget ²Deliver software that meets the customer's expectations ²Maintain a coherent and well-functioning development team ²

Dependability costs

²Dependability costs tend to increase exponentially as increasing levels of dependability are required ²There are two reasons for this: §The use of more expensive development techniques and hardware that are required to achieve the higher levels of dependability §The increased testing and system validation that is required to convince the system client and regulators that the required levels of dependability have been achieved

Dependable processes and agility

²Dependable software often requires certification so both process and product documentation has to be produced ²Up-front requirements analysis is also essential to discover requirements and requirements conflicts that may compromise the safety and security of the system ²These conflict with the general approach in agile development of co-development of the requirements and the system and minimizing documentation. ²An agile process may be defined that incorporates techniques such as iterative development, test-first development and user involvement in the development team ²So long as the team follows that process and documents their actions, agile methods can be used ²However, additional documentation and planning is essential so 'pure agile' is impractical for dependable systems engineering ²

Functional Requirements

²Describe functionality or system services. ²Depend on the type of software, expected users and the type of system where the software is used. ²Functional user requirements may be high-level statements of what the system should do. ²Functional system requirements should describe the system services in detail. imprecision- ambiguous requirements may be interpreted in different ways ²Complete §They should include descriptions of all functions required. ²Consistent §There should be no conflicts or contradictions in the descriptions of the system facilities.

Interface testing guidelines

²Design tests so that parameters to a called procedure are at the extreme ends of their ranges. ²Always test pointer parameters with null pointers. ²Design tests which cause the component to fail. ²Use stress testing in message passing systems. ²In shared memory systems, vary the order in which components are activated.

Benefits of formal specification

²Developing a formal specification requires the system requirements to be analyzed in detail. This helps to detect problems, inconsistencies and incompleteness in the requirements. ²As the specification is expressed in a formal language, it can be automatically analyzed to discover inconsistencies and incompleteness ²If you use a formal method such as the B method, you can transform the formal specification into a 'correct' program ²Program testing costs may be reduced if the program is formally verified against its specification

Development testing

²Development testing includes all testing activities that are carried out by the team developing the system. §Unit testing, where individual program units or object classes are tested. Unit testing should focus on testing the functionality of objects or methods. §Component testing, where several individual units are integrated to create composite components. Component testing should focus on testing component interfaces. §System testing, where some or all of the components in a system are integrated and the system is tested as a whole. System testing should focus on testing component interactions.

Stages of testing

²Development testing, where the system is tested during development to discover bugs and defects. ²Release testing, where a separate testing team test a complete version of the system before it is released to users. ²User testing, where users or potential users of a system test the system in their own environment.

Client-server architecture

²Distributed system model which shows how data and processing is distributed across a range of components §Can be implemented on a single computer ²Set of stand-alone servers which provide specific services such as printing, data management, etc. ²Set of clients which call on these services ²Network which allows clients to access servers

'Bad smells' in program code

²Duplicate code §The same or very similar code may be included at different places in a program. This can be removed and implemented as a single method or function that is called as required. ²Long methods §If a method is too long, it should be redesigned as a number of shorter methods ²Switch (case) statements §These often involve duplication, where the switch depends on the type of a value. The switch statements may be scattered around a program. In object-oriented languages, you can often use polymorphism to achieve the same thing. ²Data clumping §Data clumps occur when the same group of data items (fields in classes, parameters in methods) re-occur in several places in a program. These can often be replaced with an object that encapsulates all of the data. ²Speculative generality §This occurs when developers include generality in a program in case it is required in the future. This can often simply be removed.

System and component testing

²During system testing, reusable components that have been separately developed and off-the-shelf systems may be integrated with newly developed components. The complete system is then tested. ²Components developed by different team members or sub-teams may be integrated at this stage. System testing is a collective rather than an individual process. §In some companies, system testing may involve a separate testing team with no involvement from designers and programmers.

Task allocation

²During the task planning stage, the developers break down stories into development tasks. §A development task should take 4-16 hours. §All of the tasks that must be completed to implement all of the stories in that iteration are listed. §The individual developers then sign up for the specific tasks that they will implement. ²Benefits of this approach: §The whole team gets an overview of the tasks to be completed in an iteration. §Developers have a sense of ownership in these tasks and this is likely to motivate them to complete the task.

Scheduling problems

²Estimating the difficulty of problems and hence the cost of developing a solution is hard. ²Productivity is not proportional to the number of people working on a task. ²Adding people to a late project makes it later because of communication overheads. ²The unexpected always happens. Always allow contingency in planning.

Evolution and servicing

²Evolution §The stage in a software system's life cycle where it is in operational use and is evolving as new requirements are proposed and implemented in the system ²Servicing §At this stage, the software remains useful but the only changes made are those required to keep it operational i.e. bug fixes and modifications to reflect changes in the software's environment. No new functionality is added. ²Phase-out §The software may still be used but no further changes are made to it

Testing policies

²Exhaustive system testing is impossible so testing policies which define the required system test coverage may be developed. ²Examples of testing policies: §All system functions that are accessed through menus should be tested. §Combinations of functions (e.g. text formatting) that are accessed through the same menu must be tested. §Where user input is provided, all functions must be tested with both correct and incorrect input. ²

Experience-based approaches

²Experience-based techniques rely on judgments based on experience of past projects and the effort expended in these projects on software development activities. ²Typically, you identify the deliverables to be produced in a project and the different software components or systems that are to be developed. ²You document these in a spreadsheet, estimate them individually and compute the total effort required. ²It usually helps to get a group of people involved in the effort estimation and to ask each member of the group to explain their estimate.

Dependable process characteristics

²Explicitly defined §A process that has a defined process model that is used to drive the software production process. Data must be collected during the process that proves that the development team has followed the process as defined in the process model. ²Repeatable §A process that does not rely on individual interpretation and judgment. The process can be repeated across projects and with different team members, irrespective of who is involved in the development.

Types of maintenance

²Fault repairs §Changing a system to fix bugs/vulnerabilities and correct deficiencies in the way meets its requirements ²Environmental adaptation §Changing a system so that it operates in a different environment (computer, OS, etc.) from its initial implementation ²Functionality addition and modification §Modifying the system to satisfy new requirements

System dependability

²For many computer-based systems, the most important system property is the dependability of the system ²The dependability of a system reflects the user's degree of trust in that system. It reflects the extent of the user's confidence that it will operate as the users expect and that it will not 'fail' in normal use. ²Dependability covers the related systems attributes of reliability, availability and security. These are all inter-dependent.

Formal specification

²Formal methods are approaches to software development that are based on mathematical representation and analysis of software ²Formal methods include: §Formal specification §Specification analysis and proof §Transformational development §Program verification ²Formal methods significantly reduce some types of programming errors and can be cost-effective for dependable systems engineering

Acceptance of formal methods

²Formal methods have had limited impact on practical software development: §Problem owners cannot understand a formal specification and so cannot assess if it is an accurate representation of their requirements §It is easy to assess the costs of developing a formal specification but harder to assess the benefits. Managers may therefore be unwilling to invest in formal methods. §Software engineers are unfamiliar with this approach and are therefore reluctant to propose the use of FM §Formal methods are still hard to scale up to large systems §Formal specifications are not really compatible with agile development methods

Schedule presentation

²Graphical notations are normally used to illustrate the project schedule. ²These show the project breakdown into tasks. Tasks should not be too small. They should take about a week or two. ²Calendar-based §Bar charts are the most commonly used representation for project schedules. They show the schedule as activities or resources against time. ²Activity networks §Show task dependencies

Group composition

²Group composed of members who share the same motivation can be problematic §Task-oriented - everyone wants to do their own thing; §Self-oriented - everyone wants to be the boss; §Interaction-oriented - too much chatting, not enough work. ²An effective group has a balance of all types ²This can be difficult to achieve software engineers are often task-oriented ²Interaction-oriented people are very important as they can detect and defuse tensions that arise

Group communications

²Group size §The larger the group, the harder it is for people to communicate with other group members ²Group structure §Communication is better in informally structured groups than in hierarchically structured groups ²Group composition §Communication is better when there are different personality types in a group and when groups are mixed rather than single sex ²The physical work environment §Good workplace organization can help encourage communications

Causes of failure

²Hardware failure §Hardware fails because of design and manufacturing errors or because components have reached the end of their natural life ²Software failure §Software fails due to errors in its specification, design, or implementation ²Operational (human) failure §Human operators make mistakes. This is perhaps the largest single cause of system failures in socio-technical systems.

Benefits of Test Coverage

²Identifies a quantitative measure of test coverage, which is an indirect metric for quality control ²Improves the overall quality of testing ²Helps to identify what portions of the code were actually changed for a release or fix ²Helps to determine paths in code that were not tested ²Helps to identify decision points and paths used in the application ²Find gaps between requirements and test cases at unit level

Risk mitigation

²If there are serious problems with the development work that are likely to lead to significant delays, you need to initiate risk mitigation actions to reduce the risks of project failure. ²In conjunction with these actions, you also have to re-plan the project. ²This may involve renegotiating the project constraints and deliverables with the customer. A new schedule of when work should be completed also has to be established and agreed with the customer. ²

Group cohesiveness

²In a cohesive group, members consider the group to be more important than any individual in it ²The advantages of a cohesive group are: §Group quality standards can be developed by the group members §Team members learn from each other and get to know each other's work; Inhibitions caused by ignorance are reduced §Knowledge is shared. Continuity can be maintained if a group member leaves. §Refactoring and continual improvement is encouraged. Group members work collectively to deliver high quality results and fix problems, irrespective of the individuals who originally created the design or program.

Project plans

²In a plan-driven development project, a project plan sets out the resources available to the project, the work breakdown and a schedule for carrying out the work. ²Plan sections §Introduction §Project organization §Risk analysis §Hardware and software resource requirements §Work breakdown §Project schedule §Monitoring and reporting mechanisms

Agile methods and acceptance testing

²In agile methods, the user/customer is part of the development team and is responsible for making decisions on the acceptability of the system. ²Tests are defined by the user/customer and are integrated with other tests in that they are run automatically when changes are made. ²There is no separate acceptance testing process. ²Main problem here is whether or not the embedded user is 'typical' and can represent the interests of all system stakeholders. ²

Requirements and design

²In principle, requirements should state what the system should do and the design should describe how it does this. irl - inseparable

Motivation balance

²Individual motivations are made up of elements of each class ²The balance can change depending on personal circumstances and external events ²However, people are not just motivated by personal factors but also by being part of a group and culture ²People go to work because they are motivated by the people that they work with

SEI capability maturity model

²Initial- §Essentially uncontrolled ²Repeatable- §Product management procedures defined and used ²Defined- §Process management procedures and strategies defined and used ²Managed- §Quality management strategies defined and used ²Optimising- §Process improvement strategies defined and used

Partition testing

²Input data and output results often fall into different classes where all members of a class are related. ²Each of these classes is an equivalence partition or domain where the program behaves in an equivalent way for each class member. ²Test cases should be chosen from each partition.

Inspections and testing

²Inspections and testing are complementary and not opposing verification techniques. ²Both should be used during the V & V process. ²Inspections can check conformance with a specification but not conformance with the customer's real requirements. ²Inspections cannot check non-functional characteristics such as performance, usability, etc.

Interface errors

²Interface misuse §A calling component calls another component and makes an error in its use of its interface e.g. parameters in the wrong order. ²Interface misunderstanding §A calling component embeds assumptions about the behaviour of the called component which are incorrect. ²Timing errors §The called and the calling component operate at different speeds and out-of-date information is accessed.

Change implementation

²Iteration of the development process where the revisions to the system are designed, implemented and tested ²A critical difference is that the first stage of change implementation may involve program understanding, especially if the original system developers are not responsible for the change implementation ²During the program understanding phase, you have to understand how the program is structured, how it delivers functionality and how the proposed change might affect the program ²

Legacy system replacement

²Legacy system replacement is risky and expensive so businesses continue to use these systems ²System replacement is risky for a number of reasons §Lack of complete system specification §Tight integration of system and business processes §Undocumented business rules embedded in the legacy system §New software development may be late and/or over budget

Legacy system change

²Legacy systems are expensive to change for a number of reasons: §No consistent programming style §Use of obsolete programming languages with few people available with these language skills §Inadequate system documentation §System structure degradation §Program optimizations may make them hard to understand §Data errors, duplication and inconsistency § §

Legacy systems

²Legacy systems are older systems that rely on languages and technology that are no longer used for new systems development ²Legacy software may be dependent on older hardware, such as mainframe computers and may have associated legacy processes and procedures ²Legacy systems are not just software systems but are broader socio-technical systems that include hardware, software, libraries and other supporting software and business processes

Legacy system categories

²Low quality, low business value §These systems should be scrapped ²Low-quality, high-business value §These make an important business contribution but are expensive to maintain. Should be re-engineered or replaced if a suitable system is available. ²High-quality, low-business value §Replace with COTS, scrap completely or maintain ²High-quality, high business value §Continue in operation using normal system maintenance

Milestones and deliverables

²Milestones are points in the schedule against which you can assess progress, for example, the handover of the system for testing. ²Deliverables are work products that are delivered to the customer, e.g. a requirements document for the system. ²

Model driven architecture (MDA)

²Model-driven architecture (MDA) was the precursor of more general model-driven engineering Uses IML models to describe a system ²Models at different levels of abstraction are created. From a high-level, platform independent model, it is possible, in principle, to generate a working program without manual intervention.

Interaction models

²Modeling user interaction is important as it helps to identify user requirements ²Modeling system-to-system interaction highlights the communication problems that may arise ²Modeling component interaction helps us understand if a proposed system structure is likely to deliver the required system performance and dependability ²Use case diagrams and sequence diagrams may be used for interaction modeling

Existing and planned system models

²Models of the existing system are used during requirements engineering. They help clarify what the existing system does and can be used as a basis for discussing its strengths and weaknesses. These lead to requirements for the new system. ²Models of the new system are used during requirements engineering to help explain the proposed requirements to other system stakeholders. Engineers use these models to discuss design proposals and to document the system for implementation. ²In a model-driven engineering process, it is possible to generate a complete or partial system implementation from the system model. ²

Teamwork

²Most software engineering is a group activity §The development schedule for most non-trivial software projects is such that they cannot be completed by one person working alone §A good group is cohesive and has a team spirit. The people involved are motivated by the success of the group as well as by their own personal goals. ²Group interaction is a key determinant of group performance ²Flexibility in group composition is limited §Managers must do the best they can with available people ²

Non-functional requirements

²Non-functional requirements may affect the overall architecture of a system rather than the individual components. §For example, to ensure that performance requirements are met, you may have to organize the system to minimize communications between components. ²A single non-functional requirement, such as a security requirement, may generate a number of related functional requirements that define system services that are required. §It may also generate requirements that restrict existing requirements.

Interface testing

²Objectives are to detect faults due to interface errors or invalid assumptions about interfaces. ²Interface types §Parameter interfaces Data passed from one method or procedure to another. §Shared memory interfaces Block of memory is shared between procedures or functions. §Procedural interfaces Sub-system encapsulates a set of procedures to be called by other sub-systems. §Message passing interfaces Sub-systems request services from other sub-systems ²

Estimation techniques

²Organizations need to make software effort and cost estimates. There are two types of technique that can be used to do this: §Experience-based techniques The estimate of future effort requirements is based on the manager's experience of past projects and the application domain. Essentially, the manager makes an informed judgment of what the effort requirements are likely to be. §Algorithmic cost modeling In this approach, a formulaic approach is used to compute the project effort based on estimates of product attributes, such as size, and process characteristics, such as experience of staff involved. ²

Legacy system management

²Organizations that rely on legacy systems must choose a strategy for evolving these systems §Scrap the system completely and modify business processes so that it is no longer required §Continue maintaining the system §Transform the system by re-engineering to improve its maintainability §Replace the system with a new system ²The strategy chosen should depend on the system quality and its business value

Performance testing

²Part of release testing may involve testing the emergent properties of a system, such as performance and reliability. ²Tests should reflect the profile of use of the system. ²Performance tests usually involve planning a series of tests where the load is steadily increased until the system performance becomes unacceptable. ²Stress testing is a form of performance testing where the system is deliberately overloaded to test its failure behavior.

Testing strategies

²Partition testing, where you identify groups of inputs that have common characteristics and should be processed in the same way. §You should choose tests from within each of these groups. ²Guideline-based testing, where you use testing guidelines to choose test cases. §These guidelines reflect previous experience of the kinds of errors that programmers often make when developing components. ²

Architectural patterns

²Patterns (styles) are a means of representing, sharing and reusing knowledge ²An architectural pattern is a stylized description of good design practice, which has been tried and tested in different environments ²Patterns should include information about when they are and when the are not useful ²Patterns may be represented using tabular and graphical descriptions

Architecture and system characteristics

²Performance §Localize critical operations and minimize communications. Use large rather than fine-grain components. ²Security §Use a layered architecture with critical assets in the inner layers ²Safety §Localize safety-critical features in a small number of sub-systems ²Availability §Include redundant components and mechanisms for fault tolerance ²Maintainability Use fine-grain, replaceable components

Plan-driven development

²Plan-driven or plan-based development is an approach to software engineering where the development process is planned in detail. §Plan-driven development is based on engineering project management techniques and is the 'traditional' way of managing large software development projects. ²A project plan is created that records the work to be done, who will do it, the development schedule and the work products. ²Managers use the plan to support project decision making and as a way of measuring progress.

Planning stages

²Planning Occurs During the Project: §At the proposal stage, when you are bidding for a contract to develop or provide a software system. §During the project startup phase(initiation), when you have to plan who will work on the project, how the project will be broken down into increments, how resources will be allocated across your company, etc. §Periodically throughout the project, when you modify your plan in the light of experience gained and information from monitoring the progress of the work.

Approaches to agile planning

²Planning in Scrum §Covered in Chapter 3 ²Based on managing a project backlog (things to be done) with daily reviews of progress and problems ²The planning game §Developed originally as part of Extreme Programming (XP) §Dependent on user stories as a measure of progress in the project

Proposal planning

²Planning may be necessary with only outline software requirements. ²The aim of planning at this stage is to provide information that will be used in setting a price for the system to customers. ²Project pricing involves estimating how much the software will cost to develop, taking factors such as staff costs, hardware costs, software costs, etc. into account ²All these items are usually put into a project proposal

Change prediction

²Predicting the number of changes requires and understanding of the relationships between a system and its environment ²Tightly coupled systems require changes whenever the environment is changed ²Factors influencing this relationship are §Number and complexity of system interfaces §Number of inherently volatile system requirements §The business processes where the system is used

Complexity metrics

²Predictions of maintainability can be made by assessing the complexity of system components ²Studies have shown that most maintenance effort is spent on a relatively small number of system components ²Complexity depends on §Complexity of control structures §Complexity of data structures §Object, method (procedure) and module size

Process diversity and redundancy

²Process activities, such as validation, should not depend on a single approach, such as testing, to validate the system ²Redundant and diverse process activities are important especially for verification and validation ²Multiple, different process activities that complement each other and allow for cross-checking help to avoid process errors, which may lead to errors in the software ²

Process improvement activities

²Process measurement -measurements of software attributes forms a baseline that helps you decide if process improvements have been effective. Wherever possible, quantitative process data should be collected metrics could be time taken resources used number of occurrences the improvement driver is the organization objectives ²Process analysis- The current process is assessed, and process weaknesses and bottlenecks are identified. may create process model or map Process changes- are proposed to address some of the identified process weaknesses

Process metrics

²Process metrics may be used to assess maintainability §Number of requests for corrective maintenance §Average time required for impact analysis §Average time taken to implement a change request §Number of outstanding change requests ²If any or all of these is increasing, this may indicate a decline in maintainability

Transaction processing systems

²Process user requests for information from a database or requests to update the database ²From a user perspective a transaction is: §Any coherent sequence of operations that satisfies a goal §For example - find the times of flights from London to Paris ²Users make asynchronous requests for service which are then processed by a transaction manager

Project activities

²Project activities (tasks) are the basic planning element. Each activity has: §a duration in calendar days or months, §an effort estimate, which shows the number of person-days or person-months to complete the work, §a deadline by which the activity should be complete, §a defined end-point, which might be a document, the holding of a review meeting, the successful execution of all tests, etc. ²

Universal management activities

²Project planning §Project managers are responsible for planning, estimating and scheduling project development and assigning people to tasks §Covered in Chapter 23 ²Risk management §Project managers assess the risks that may affect a project, monitor these risks and take action when problems arise ²People management §Project managers have to choose people for their team and establish ways of working that leads to effective team performance § ²Reporting §Project managers are usually responsible for reporting on the progress of a project to customers and to the managers of the company developing the software ²Proposal writing §The first stage in a software project may involve writing a proposal to win a contract to carry out an item of work. The proposal describes the objectives of the project and how it will be carried out ²

The planning process

²Project planning is an iterative process that starts when you create an initial project plan during the project startup phase. ²Plan changes are inevitable. §As more information about the system and the project team becomes available during the project, you should regularly revise the plan to reflect requirements, schedule and risk changes. §Changing business goals also leads to changes in project plans. As business goals change, this could affect all projects, which may then have to be re-planned. ²

Project scheduling

²Project scheduling is the process of deciding how the work in a project will be organized as separate tasks, and when and how these tasks will be executed. ²You estimate the calendar time needed to complete each task, the effort required and who will work on the tasks that have been identified. ²You also have to estimate the resources needed to complete each task, such as the disk space required on a server, the time required on specialized hardware, such as a simulator, and what the travel budget will be.

Generalization

²Rather than learn the detailed characteristics of every entity that we experience, we place these entities in more general classes and transfer their characteristics to their subclasses (or specialized classes) ²In modeling systems, it is often useful to examine the classes in a system to see if there is scope for generalization. If changes are proposed, then you do not have to look at all classes in the system to see if they are affected by the change. ²In object-oriented languages, such as Java, generalization is implemented using the class inheritance mechanisms built into the language ²In a generalization, the attributes and operations associated with higher-level classes are also associated with the lower-level classes ² The lower-level classes are sub-classes that inherit the attributes and operations from their super-classes. These lower-level classes then add more specific attributes and operations.

Refactoring and reengineering

²Re-engineering takes place after a system has been maintained for some time and maintenance costs are increasing. You use automated tools to process and re-engineer a legacy system to create a new system that is more maintainable. ²Refactoring is a continuous process of improvement throughout the development and evolution process. It is intended to avoid the structure and code degradation that increases the costs and difficulties of maintaining a system.

Event-driven modeling

²Real-time systems are often event-driven, with minimal data processing. For example, a landline phone switching system responds to events such as 'receiver off hook' by generating a dial tone. ²Event-driven modeling shows how a system responds to external and internal events ²It is based on the assumption that a system has a finite number of states and that events (stimuli) may cause a transition from one state to another

Redundancy and diversity

²Redundancy §Keep more than a single version of critical components so that if one fails then a backup is available ²Diversity §Provide the same functionality in different ways in different components so that they will not fail in the same way ²Redundant and diverse components should be independent so that they will not suffer from 'common-mode' failures §For example, components implemented in different programming languages means that a compiler fault will not affect all of them examples: ²Redundancy. Where availability is critical (e.g., in e-commerce systems), companies normally keep backup servers and switch to these automatically if failure occurs ²Diversity. To provide resilience against external attacks, different servers may be implemented using different operating systems (e.g. Windows and Linux)

Software reengineering

²Reengineering = Restructuring or rewriting part or all of a legacy system without changing its functionality ²Applicable where some but not all sub-systems of a larger system require frequent maintenance ²Reengineering involves adding effort to make them easier to maintain. The system may be restructured and redocumented. advantages ²Reduced risk §There is a high risk in new software development. There may be development problems, staffing problems and specification problems. ²Reduced cost §The cost of re-engineering is often significantly less than the costs of developing new software

Refactoring

²Refactoring is the process of making improvements to a program to slow down degradation through change ²You can think of refactoring as 'preventative maintenance' that reduces the problems of future change ²Refactoring involves modifying a program to improve its structure, reduce its complexity, or make it easier to understand ²When one refactors a program, one should not add functionality but rather concentrate on program improvement

Agile planning stages

²Release planning, which looks ahead for several months and decides on the features that should be included in a release of a system. ²Iteration planning, which has a shorter term outlook, and focuses on planning the next increment of a system. This is typically 2-4 weeks of work for the team. ²

Release testing and system testing

²Release testing is a form of system testing. ²Important differences: §A separate team that has not been involved in the system development, should be responsible for release testing. §System testing by the development team should focus on discovering bugs in the system (defect testing). The objective of release testing is to check that the system meets its requirements and is good enough for external use (validation testing). ²

Release testing

²Release testing is the process of testing a particular release of a system that is intended for use outside of the development team. ²The primary goal of the release testing process is to convince the supplier of the system that it is good enough for use. §Release testing, therefore, has to show that the system delivers its specified functionality, performance and dependability, and that it does not fail during normal use. ²Release testing is usually a black-box testing process where tests are only derived from the system specification. ²

Dependable process activities

²Requirements reviews to check that the requirements are, as far as possible, complete and consistent ²Requirements management to ensure that changes to the requirements are controlled and that the impact of proposed requirements changes is understood. ²Formal specification, where a mathematical model of the software is created and analyzed ²System modeling, where the software design is explicitly documented as a set of graphical models, and the links between the requirements and these models are documented ²Design and program inspections, where the different descriptions of the system are inspected and checked by different people. ²Static analysis, where automated checks are carried out on the source code of the program. ²Test planning and management, where a comprehensive set of system tests is designed. §The testing process has to be carefully managed to demonstrate that these tests provide coverage of the system requirements and have been correctly applied in the testing process.

Requirements based testing

²Requirements-based testing involves examining each requirement and developing a test or tests for it. ²Mentcare system requirements: §If a patient is known to be allergic to any particular medication, then prescription of that medication shall result in a warning message being issued to the system user. §If a prescriber chooses to ignore an allergy warning, they shall provide a reason why this has been ignored. §

Risk management

²Risk management is concerned with identifying risks and drawing up plans to minimise their effect on a project ²Software risk management is important because of the inherent uncertainties in software development §These uncertainties stem from loosely defined requirements, requirements changes due to changes in customer needs, difficulties in estimating the time and resources required for software development, and differences in individual skills ²You have to anticipate risks, understand the impact of these risks on the project, the product and the business, and take steps to avoid these risks

Dependability attribute dependencies

²Safe system operation depends on the system being available and operating reliably ²A system may be unreliable because its data has been corrupted by an external attack ²Denial of service attacks on a system are intended to make it unavailable ²If a system is infected with a virus, you cannot be confident in its reliability or safety

sequence diagrams

²Sequence diagrams are part of the UML and are used to model the interactions between the actors and the objects within a system ²A sequence diagram shows the sequence of interactions that take place during a particular use case ²The objects and actors involved are listed along the top of the diagram, with dotted lines (representing object timelines) drawn vertically from these ²Interactions between objects are indicated by annotated arrows, with the execution of object methods shown on timelines

Component testing

²Software components are often composite components that are made up of several interacting objects. §For example, in the weather station system, the reconfiguration component includes objects that deal with each aspect of the reconfiguration. ²You access the functionality of these objects through the defined component interface. ²Testing composite components should therefore focus on showing that the component interface behaves according to its specification. §You can assume that unit tests on the individual objects within the component have been completed.

Evolution processes

²Software evolution processes depend on §The type of software being maintained §The development processes used §The skills and experience of the people involved ²Proposals for change are the driver for system evolution §Should be linked with components that are affected by the change, thus allowing the cost and impact of the change to be estimated ²Change identification and evolution continues throughout the system lifetime

Requirements elicitation and analysis

²Sometimes called requirements elicitation or requirements discovery. ²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. ²May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders. ²Find Requirements! ²Stages include: §Requirements discovery, may use interviews §Requirements classification and organization, §Requirements prioritization and negotiation, §Requirements specification. problems: ²Stakeholders don't know what they really want. ²Stakeholders express requirements in their own terms. ²Different stakeholders may have conflicting requirements. ²Organisational and political factors may influence the system requirements. The requirements change during the analysis process. New stakeholders may emerge and the business environment may change

Reengineering process activities

²Source code translation §Convert code to a new language ²Reverse engineering §Analyze the program to understand it ²Program structure improvement §Restructure automatically for understandability ²Program modularization §Reorganize the program structure ²Data reengineering Clean-up and restructure system data

Classes of error

²Specification and design errors and omissions §Developing and analyzing a formal model of the software may reveal errors and omissions in the software requirements. If the model is generated automatically or systematically from source code, analysis using model checking can find undesirable states that may occur such as a deadlock in a concurrent system. ²Inconsistences between a specification and a program §If a refinement method is used, mistakes made by developers that make the software inconsistent with the specification are avoided. Program proving discovers inconsistencies between a program and its specification. ²

Project scheduling activities

²Split project into tasks and estimate time and resources required to complete each task. ²Organize tasks concurrently to make optimal use of workforce. ²Minimize task dependencies to avoid delays caused by one task waiting for another to complete. ²Dependent on project managers intuition and experience.

Advantages of explicit architecture

²Stakeholder communication -Architecture may be used as a focus of discussion by system stakeholders ²System analysis- Means that analysis of whether the system can meet its non-functional requirements is possible. ²Large-scale reuse §The architecture may be reusable across a range of systems §Product-line architectures may be developed

Repository architecture

²Sub-systems must exchange data. This may be done in two ways: §Shared data is held in a central database or repository and may be accessed by all sub-systems; §Each sub-system maintains its own database and passes data explicitly to other sub-systems. ²When large amounts of data are to be shared, the repository model of sharing is most commonly used as this is an efficient data sharing mechanism

Importance of dependability

²System failures may have widespread effects with large numbers of people affected by the failure ²Systems that are not dependable and are unreliable, unsafe or insecure may be rejected by their users ²The costs of system failure may be very high if the failure leads to economic losses or physical damage ²Undependable systems may cause information loss with a high consequent recovery cost

Legacy system components

²System hardware Legacy systems may have been written for hardware that is no longer available. ²Support software The legacy system may rely on a range of support software, which may be obsolete or unsupported. ²Application software The application system that provides the business services is usually made up of a number of application programs. ² Application data These are data that are processed by the application system. They may be inconsistent, duplicated or held in different databases. ²Business processes These are processes that are used in the business to achieve some business objective. Business processes may be designed around a legacy system and constrained by the functionality that it provides. ²Business policies and rules These are definitions of how the business should be carried out and constraints on the business. Use of the legacy application system may be embedded in these policies and rules.

Architecture reuse

²Systems in the same domain often have similar architectures that reflect domain concepts application product lines build around core architecture ²The architecture of a system may be designed around one of more architectural patterns or 'styles'. §These capture the essence of an architecture and can be instantiated in different ways

How Test Coverage can be accomplished?

²Test coverage can be done by exercising the static review techniques like peer reviews, inspections, and walkthrough ²At code level or unit test level, test coverage can be achieved by using automated code coverage or unit test coverage tools ²Functional test coverage can be done with the help of proper test management tools

Testing guidelines (sequences)

²Test software with sequences which have only a single value. ²Use sequences of different sizes in different tests. ²Derive tests so that the first, middle and last elements of the sequence are accessed. ²Test with sequences of zero length.

Test-driven development

²Test-driven development (TDD) is an approach to program development in which you inter-leave testing and code development. ²Tests are written before code and 'passing' the tests is the critical driver of development. ²You develop code incrementally, along with a test for that increment. You don't move on to the next increment until the code that you have developed passes its test. ²TDD was introduced as part of agile methods such as Extreme Programming. However, it can also be used in plan-driven development processes. Benefits ²Code coverage §Every code segment that you write has at least one associated test so all code written has at least one test. ²Regression testing §A regression test suite is developed incrementally as a program is developed. ²Simplified debugging §When a test fails, it should be obvious where the problem lies. The newly written code needs to be checked and modified. ²System documentation §The tests themselves are a form of documentation that describe what the code should be doing.

Plan-driven development - pros and cons

²The arguments in favor of a plan-driven approach are that early planning allows organizational issues (availability of staff, other projects, etc.) to be closely taken into account, and that potential problems and dependencies are discovered before the project starts, rather than once the project is underway. §Allows for risk mitigation ²The principal argument against plan-driven development is that many early decisions have to be revised because of changes to the environment in which the software is to be developed and used.

Problem with experience-based approaches

²The difficulty with experience-based techniques is that a new software project may not have much in common with previous projects. ²Software development changes very quickly and a project will often use unfamiliar techniques such as web services, application system configuration or HTML5. ²If you have not worked with these techniques, your previous experience may not help you to estimate the effort required, making it more difficult to produce accurate costs and schedule estimates. ²

Automated testing

²Whenever possible, unit testing should be automated so that tests are run and checked without manual intervention. ²In automated unit testing, you make use of a test automation framework (such as JUnit) to write and run your program tests. ²Unit testing frameworks provide generic test classes that you extend to create specific test cases. They can then run all of the tests that you have implemented and report, often through some GUI, on the success of otherwise of the tests.

Validation and defect testing

²The first goal leads to validation testing §To demonstrate to the developer and the customer that the software meets its requirements. §You expect the system to perform correctly using a given set of test cases that reflect the system's expected use. A successful test shows that the system operates as intended ²The second goal leads to defect testing §To discover situations in which the behavior of the software is incorrect, undesirable or does not conform to its specification. §The test cases are designed to expose defects. §A successful test is a test that makes the system perform incorrectly and so exposes a defect in the system. deliberately try to break the system

Regulation and compliance

²The general model of economic organization that is now almost universal in the world is that privately owned companies offer goods and services and make a profit on these ²To ensure the safety of their citizens, most governments regulate (limit the freedom of) privately owned companies so that they must follow certain standards to ensure that their products are safe and secure

Informal groups

²The group acts as a whole and comes to a consensus on decisions affecting the system ²The group leader serves as the external interface of the group but does not allocate specific work items ²Rather, work is discussed by the group as a whole and tasks are allocated according to ability and experience ²This approach is successful for groups where all members are experienced and competent

Personality types

²The needs hierarchy is almost certainly an over-simplification of motivation in practice ²Motivation should also take into account different personality types: §Task-oriented people, who are motivated by the work they do in software engineering §Interaction-oriented people, who are motivated by the presence and actions of co-workers §Self-oriented people, who are principally motivated by personal success and recognition

The effectiveness of a team

²The people in the group §You need a mix of people in a project group as software development involves diverse activities such as negotiating with clients, programming, testing and documentation ²The group organization §A group should be organized so that individuals can contribute to the best of their abilities and tasks can be completed as expected ²Technical and managerial communications §Good communications between group members, and between the software engineering team and other project stakeholders, is essential ²

Story-based planning

²The planning game is based on user stories that reflect the features that should be included in the system. ²The project team read and discuss the stories and rank them in order of the amount of time they think it will take to implement the story. ²Stories are assigned 'effort points' reflecting their size and difficulty of implementation ²The number of effort points implemented per day is measured giving an estimate of the team's 'velocity' ²This allows the total effort required to implement the system to be estimated

Use of formal methods

²The principal benefits of formal methods are in reducing the number of faults in systems ²Consequently, their main area of applicability is in dependable systems engineering. There have been several successful projects where formal methods have been used in this area. ²In this area, the use of formal methods is most likely to be cost-effective because high system failure costs must be avoided.

software specification

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

Software management distinctions

²The product is intangible §Software cannot be seen or touched. Software project managers cannot see progress by simply looking at the artefact that is being constructed. ²Many software projects are 'one-off' projects §Large software projects are usually different in some ways from previous projects. Even managers who have lots of previous experience may find it difficult to anticipate problems. ²Software processes are variable and organization specific §We still cannot reliably predict when a particular software process is likely to lead to development problems

Development planning

²The project plan should be regularly amended as the project progresses and you know more about the software and its development ²The project schedule, cost-estimate and risks have to be regularly revised

Reengineering cost factors

²The quality of the software to be reengineered ²The tool support available for reengineering ²The extent of the data conversion which is required ²The availability of expert staff for reengineering §This can be a problem with old systems based on technology that is no longer widely used

Pricing to win

²The software is priced according to what the software developer believes the buyer is willing to pay ²If this is less that the development costs, the software functionality may be reduced accordingly with a view to extra functionality being added in a later release ²Additional costs may be added as the requirements change and these may be priced at a higher level to make up the shortfall in the original price

Choosing unit test cases

²The test cases should show that, when used as expected, the component that you are testing does what it is supposed to do. ²If there are defects in the component, these should be revealed by test cases. ²This leads to 2 types of unit test case: §The first of these should reflect normal operation of a program and should show that the component works as expected. §The other kind of test case should be based on testing experience of where common problems arise. It should use abnormal inputs to check that these are properly processed and do not crash the component.

Issues in business value assessment

²The use of the system §If systems are only used occasionally or by a small number of people, they may have a low business value ²The business processes that are supported §A system may have a low business value if it forces the use of inefficient business processes ²System dependability §If a system is not dependable and the problems directly affect business customers, the system has a low business value ²The system outputs §If the business depends on system outputs, then the system has a high business value ²

Risk classification

²There are two dimensions of risk classification §The type of risk (technical, organizational, etc.) §What is affected by the risk ²Project risks affect schedule or resources ²Product risks affect the quality or performance of the software being developed ²Business risks affect the organization developing or procuring the software ²

Software inspections

²These involve people examining the source representation with the aim of discovering anomalies and defects. ²Inspections not require execution of a system so may be used before implementation. ²They may be applied to any representation of the system (requirements, design,configuration data, test data, etc.). They have been shown to be an effective technique for discovering program errors advantages ²During testing, errors can mask (hide) other errors. Because inspection is a static process, you don't have to be concerned with interactions between errors. ²Incomplete versions of a system can be inspected without additional costs. If a program is incomplete, then you need to develop specialized test harnesses to test the parts that are available. ²As well as searching for program defects, an inspection can also consider broader quality attributes of a program, such as compliance with standards, portability and maintainability.

State machine models

²These model the behavior of the system in response to external and internal events ²They show the system's responses to stimuli so are often used for modelling real-time systems ²State machine models show system states as nodes and events as arcs between these nodes (event names are shown on transitions). When an event occurs, the system moves from one state to another. ²Statecharts are an integral part of the UML and are used to represent state machine models

Dependable processes

²To ensure a minimal number of software faults, it is important to have a well-defined, repeatable software process ²A well-defined repeatable process is one that does not depend entirely on individual skills; rather, it can be enacted by different people ²Regulators use information about the process to check if good software engineering practice has been used ²For fault detection, it is clear that the process activities should include significant effort devoted to verification and validation

Pricing strategies

²Under pricing §A company may underprice a system in order to gain a contract that allows them to retain staff for future opportunities §A company may underprice a system to gain access to a new market area ²Increased pricing §The price may be increased when a buyer wishes a fixed-price contract and so the seller increases the price to allow for unexpected risks

Urgent change requests

²Urgent changes may have to be implemented without going through all stages of the software engineering process §If a serious system fault has to be repaired to allow normal operation to continue §If changes to the system's environment (e.g. an OS upgrade) have unexpected effects §If there are business changes that require a very rapid response (e.g. the release of a competing product)

Business process assessment

²Use a viewpoint-oriented approach and seek answers from system stakeholders §Is there a defined process model and is it followed? §Do different parts of the organization use different processes for the same function? §How has the process been adapted? §What are the relationships with other business processes and are these necessary? §Is the process effectively supported by the legacy application software? ²Example - a travel ordering system may have a low business value because of the widespread use of web-based ordering

Use case modeling

²Use cases were developed originally to support requirements elicitation and now are incorporated into the UML ²Each use case represents a discrete task that involves external interaction with an actor ²Actors in a use case may be people or other systems

Use cases

²Use-cases are a kind of scenario that are included in the UML. ²Use cases identify the actors in an interaction and which describe the interaction itself. ²A set of use cases should describe all possible interactions with the system. ²High-level graphical model supplemented by more detailed tabular description (see Chapter 5). ²UML sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system.

User testing

²User or customer testing is a stage in the testing process in which users or customers provide input and advice on system testing. ²User testing is essential, even when comprehensive system and release testing have been carried out. §The reason for this is that influences from the user's working environment have a major effect on the reliability, performance, usability and robustness of a system. These cannot be replicated in a testing environment. Types of user testing ²Alpha testing §Users of the software work with the development team to test the software at the developer's site. ²Beta testing §A release of the software is made available to users to allow them to experiment and to raise problems that they discover with the system developers. ²Acceptance testing §Customers test a system to decide whether or not it is ready to be accepted from the system developers and deployed in the customer environment. Primarily for custom systems.

Requirements specification

²User requirements have to be understandable by end-users and customers who do not have a technical background. ²System requirements are more detailed requirements and may include more technical information. ²The requirements may be part of a contract for the system development for ways of writing see power point 27

Maintenance costs

²Usually greater than development costs (2x to 100x depending on the application) ²Affected by both technical and non-technical factors ²Increases as software is maintained. Maintenance corrupts the software structure so it makes further maintenance more difficult. ²Ageing software can have high support costs (e.g. old languages, compilers) ²It is usually more expensive to add new features to a system during maintenance than it is to add the same features during development §A new team has to understand the programs being maintained §Separating maintenance and development means there is no incentive for the development team to write maintainable software §Program maintenance work is unpopular •Maintenance staff are often inexperienced and have limited domain knowledge §As programs age, their structure degrades and they become harder to change

Formal approaches

²Verification-based approaches §Different representations of a software system such as a specification and a program implementing that specification are proved to be equivalent §This demonstrates the absence of implementation errors ²Refinement-based approaches §A representation of a system is systematically transformed into another, lower-level representation, e.g. a specification is transformed automatically into an implementation. §This means that, if the transformation is correct, the representations are equivalent

System measurement

²You may collect quantitative data to make an assessment of the quality of the application system §The number of system change requests; The higher this accumulated value, the lower the quality of the system. §The number of different user interfaces used by the system; The more interfaces, the more likely it is that there will be inconsistencies and redundancies in these interfaces. §The volume of data used by the system. As the volume of data (number of files, size of database, etc.) processed by the system increases, so too do the inconsistencies and errors in that data. §Cleaning up old data is a very expensive and time-consuming process

Planning assumptions

²You should make realistic rather than optimistic assumptions when you are defining a project plan. ²Problems of some description always arise during a project, and these lead to project delays. ²Your initial assumptions and scheduling should therefore take unexpected problems into account. ²You should include contingency in your plan so that if things go wrong, then your delivery schedule is not seriously disrupted.

Requirements engineering processes

²there are a number of generic activities common to all processes §Requirements elicitation; §Requirements analysis; §Requirements validation; §Requirements management. ²In practice, Requirements Engineering is an iterative activity in which these processes are interleaved.

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

Agile and plan-driven 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. ▪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. ▪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.

Extreme programming (XP)

▪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

Test-first development

▪Test-first development ▪Incremental test development from scenarios ▪User involvement in test development and validation ▪Automated test harnesses are used to run all component tests each time that a new release is built++ problems people don't like to write test some test can be difficult to write when the product is not yet complete difficult to judge the completeness

Agile methods and software maintenance

✧Key problems are: ▪Lack of product documentation ▪Keeping customers involved in the development process ▪Maintaining the continuity of the development team ✧Agile development relies on the development team knowing and understanding what has to be done ✧For long-lifetime systems, this is a real problem as the original developers will not always work on the system

Contractual issues agile

✧Most software contracts for custom systems are based around a specification, which sets out what has to be implemented by the system developer for the system customer ✧However, this precludes interleaving specification and development as is the norm in agile development ✧A contract that pays for developer time rather than functionality is required ▪However, this is seen as a high risk by many legal departments because what has to be delivered cannot be guaranteed

Agile development

✧Rapid development and delivery is now often the most important requirement for software systems ✧Plan-driven development is essential for some types of system but does not meet these business needs aglie was 1990s to reduce delivery times for working systems ✧Program specification, design and implementation are inter-leaved ✧The system is developed as a series of versions or increments with stakeholders involved in version specification and evaluation ✧Frequent delivery of new versions for evaluation ✧Extensive tool support (e.g. automated testing tools) used to support development ✧Minimal documentation - focus on working code Best used in a small or medium sized product ✧Custom system development within an organization, where there is a clear commitment from the customer to become involved in the development process and where there are few external rules and regulations that affect the software