WEEK 1: OVERVIEW 1. Software What is software? □ Computer programs and associated documentation.

□ Software products □ may be with requirements elicitation and validation; □ In design processes to explore options and develop a UI design; □ In the testing process to run back- document for senior management showing how the project is making a very important contribution to the goals of the business. Database
developed for a particular customer or □ may be developed for a general market. Role of software [1] □ Is software important? Why? □ Give ten to-back tests. 38 Benefits of prototyping □ Improved system usability. □ A closer match to users' real needs. □ Improved design quality. □ Improved performance Investigate the possibility of buying a higher-performance database. Underestimated development time Investigate buying-in
examples of software 6 Role of software [2] □ The economies of ALL developed nations are dependent on software. □ More and more systems are maintainability. □ Reduced development effort. 39 The process of prototype development 40 Prototype development □ May be based on rapid components; investigate use of a program generator. 43 Risk monitoring □ Assess each identified risks regularly to decide whether or not it is
software controlled □ Software engineering is concerned with theories, methods and tools for professional software development. Software prototyping languages or tools □ May involve leaving out functionality □ Prototype should focus on areas of the product that are not well- becoming less or more probable. □ Also assess whether the effects of the risk have changed. □ Each key risk should be discussed at management
products □ Generic products □ Stand-alone systems that are marketed and sold to any customer who wishes to buy them. □ The specification of understood; □ □ Error checking and recovery may not be included in the prototype; Focus on functional rather than non-functional requirements progress meetings. 44 Risk indicators Risk type Potential indicators Technology Late delivery of hardware or support software; many reported
what the software should do is owned by the software developer and decisions on software change are made by the developer. □ Customized such as reliability and security 41 Throwaway prototypes □ Prototypes should be discarded after development as they are not a good basis for a technology problems. People Poor staff morale; poor relationships amongst team members; high staff turnover. Organizational Organizational
products □ Software that is commissioned by a specific customer to meet their own needs. □ The specification of what the software should do is production system: □ It may be impossible to tune the system to meet nonfunctional requirements; □ Prototypes are normally undocumented; □ gossip; lack of action by senior management. Reluctance by team members to use tools; complaints Tools about CASE tools; demands for higher-
owned by the customer for the software and they make decisions on software changes that are required. 8 Essential attributes of good software The prototype structure is usually degraded through rapid change; □ The prototype probably will not meet normal organisational quality standards. powered workstations. Requirements Many requirements change requests; customer complaints. Estimation Failure to meet agreed schedule;
Maintainability □ Software should evolve to meet the changing needs of customers. □ Dependability and security □ Software dependability includes 42 Incremental delivery The development and delivery is broken down into increments with each increment delivering part of the required failure to clear reported defects. 2. Managing people □ People are an organisation’s most important assets. □ The tasks of a manager are
a range of characteristics including reliability, security and safety. Efficiency □ Software should not make wasteful use of system resources. functionality. User requirements are prioritised and the highest priority requirements are included in early increments. Once the development of an essentially people-oriented. Unless there is some understanding of people, management will be unsuccessful. □ Poor people management is an
Acceptability □ Software must be acceptable to the type of users for which it is designed. 9 2. Software engineering What is software engineering? increment is started, the requirements are frozen though requirements for later increments can continue to evolve. 43 ^ Incremental development important contributor to project failure. People management factors □ □ □ Consistency □ Team members should all be treated in a comparable way
Software engineering is an engineering discipline that is concerned with all aspects of software production from the early stages of system and delivery □ Incremental development □ Develop the system in increments and evaluate each increment before proceeding to the development without favourites or discrimination. Respect □ Different team members have different skills and these differences should be respected. Inclusion □
specification through to maintaining the system after it has gone into use. □ Engineering discipline □ Using appropriate theories and methods to of the next increment; □ Normal approach used in agile methods; □ Evaluation done by user/customer proxy. □ Incremental delivery □ Deploy an 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
solve problems bearing in mind organizational and financial constraints. All aspects of software production □ Not just technical process of increment for use by end-users; □ More realistic evaluation about practical use of software; □ Difficult to implement for replacement systems as what is going badly in a project. □ Motivating people □ An important role of a manager is to motivate the people working on a project. □ Means
development. Also project management and the development of tools, methods etc. to support software production. Software costs □ Software increments have less functionality than the system being replaced. 44 Incremental delivery Define outline requirements Assign requirements to organizing the work and the working environment to encourage people to work effectively. □ If people are not motivated, they will not be interested
costs often dominate computer system costs. The costs of software on a PC are often greater than the hardware cost. □ Software costs more to increments Design system architecture Develop system increment System incomplete? Validate increment Integrate increment Validate system 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
maintain than it does to develop. For systems with a long life, maintenance costs may be several times development costs. □ Software engineering Deploy increment System w complete? Final system 45 Incremental delivery benefits Customer value can be delivered with each increment so organization. □ Is a complex issue but it appears that there are different types of motivation based on: □ Basic needs (e.g. food, sleep, etc.);
is concerned with costeffective software development. 16 Costs of software engineering □ □ Roughly 60% of software costs are development system functionality is available earlier. Early increments act as a prototype to help elicit requirements for later increments. Lower risk of overall Personal needs (e.g. respect, self-esteem); Social nẹeds(e-g. to be accepted as nart-pf-a-group). Need satisfaction □ In software development
costs, 40% are testing costs. For custom software, evolution costs often exceed development costs. Software engineering vs. Computer science? project failure. The highest priority system services tend to receive the most testing. 46 Incremental delivery problems Most systems require a set groups, basic physiological and safety needs are not an issue. □ Social □ Provide communal facilities; □ Allow informal communications e.g. via
□ Computer science focuses on theory and fundamentals. □ Software engineering is concerned with the practicalities of developing and delivering of basic facilities that are used by different parts of the system. □ As requirements are not defined in detail until an increment is to be implemented, social networking □ Esteem □ □ □ Self-realization □ Training - people want to learn more; □R efttonsibility. Recognition of achievements;
useful software. 19 Software engineering vs. System engineering? System engineering is concerned with all aspects of computer-based systems it can be hard to identify common facilities that are needed by all increments. The essence of iterative processes is that the specification is Appropriate rewards. 51 Personality types needs hierarchy is almost certainly an over- The simplification of motivation in practice. □ Motivation
development including hardware, software and process engineering. □ Software engineering is part of this more general process. Software developed in conjunction with the software. □ However, this conflicts with the procurement model of many organizations, where the complete should also take into account different personality types: □ Task-oriented; □ Self-oriented; □ Interaction-oriented. 52 Personality types □ Task-
engineering System engineering 20 Best software engineering techniques and methods? □ While all software projects have to be professionally system specification is part of the system development contract. Procurement is a strategic process that involves the acquisition of goods and oriented. □ The motivation for doing the work is the work itself; □ Self-oriented. □ The work is a means to an end which is the achievement of
managed and developed, different techniques are appropriate for different types of system. □ You can't say that one method is better than another. services 47 48 4. Boehm's spiral model □ Process is represented as a spiral rather than as a sequence of activities with backtracking. □ Each loop individual goals - e.g. to get rich, to play tennis, to travel etc.; □ Interaction-oriented □ The principal motivation is the presence and actions of co-
Importance of software engineering □ More and more, individuals and society rely on advanced software systems. We need to be able to produce in the spiral represents a phase in the process. □ No fixed phases such as specification or design -loops in the spiral are chosen depending on workers. People go to work because they like to go to work. 53 □ □ Motivation balance □ Individual motivations are made up of elements of each
reliable and trustworthy systems economically and quickly. □ It is usually cheaper, in the long run, to use software engineering methods and what is required. □ Risks are explicitly assessed and resolved throughout the process. 49 Boehm's spiral model of the software process Determine class. The balance can change depending on personal circumstances and external events. However, people are not just motivated by personal
techniques for software systems rather than just write the programs as if it was a personal programming project. □ For most types of system, the objectives, alternatives and constraints 50 Evaluate alternatives, identify, resolve risks Prototype 2 Simulations, models, benchmarks Develop, 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. 3.
majority of costs are the costs of changing the software after it has gone into use. 23 3. Software process 24 What is software process? □ A verify next-level product Product design Opera- tional protoype S/W Detailed design Code Unit test Plan next phase REVIEW Requirements plan Teamwork □ □ □ Most software engineering is a group activity □ The development schedule for most non-trivial software projects is such that they
sequence of activities that leads to production of a software product. □ There are four fundamental activities that common to all software Life-cycle plan Development plan Integration and test plan Risk analysis Risk analysis Risk analysis Risk analysis Proto- type 1 Concept of 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
processes. the are 25 Software process activities □ Software specification □ customers and engineers define the software that is to be produced Operation requirements Requirement validation Design V&V Integration ------ Acceptance ■ test Service test Spiral model sectors □ Objective success of the group as well as by their own personal goals. Group interaction is a key determinant of group performance. Flexibility in group
and the constraints on its operation. □ Software development □ software is designed and programmed. □ Software validation □ software is checked setting □ Specific objectives for the phase are identified. □ Risk assessment and reduction □ Risks are assessed and activities put in place to composition is limited □ Managers must do the best they can with available people. 56 Group cohesiveness In a cohesive group, members
to ensure that it is what the customer requires. □ Software evolution □ software is modified to reflect changing customer and et requirements. 26 reduce the key risks. □ Development and validation □ A development model for the system is chosen which can be any of the generic models. □ consider the group to be more important than any individual in it. The advantages of a cohesive group are: □ Group quality standards can be
General issues that affect software [1] □ Heterogeneity □ Increasingly, systems are required to operate as distributed systems across networks that Planning □ The project is reviewed and the next phase of the spiral is planned. 51 Spiral model usage □ Spiral model has been very influential in developed by the group members. □ Team members learn from each other and get to know each other's work; Inhibitions caused by ignorance are
include different types of computer and mobile devices. □ Business and social change □ Business and society are changing incredibly quickly as helping people think about iteration in software processes and introducing the risk-driven approach to development. □ In practice, however, the reduced. □ Knowledge is shared. Continuity can be maintained if a group member leaves. □ Refactoring and continual improvement is
emerging economies develop and new technologies become available. They need to be able to change their existing software and to rapidly model is rarely used as published for practical software development. 52 The Rational Unified Process The Rational Unified Process □ A modern encouraged. Group members work collectively to deliver high quality results and fix problems, irrespective of the individuals whoWginally created
develop new software. 27 General issues that affect software [2] □ Security and trust □ As software is intertwined with all aspects of our lives, it is generic process derived from the work on the UML and associated process. □ Brings together aspects of the 3 generic process models discussed the design or program. Effectiveness of a team The people in the group □ You need a mix of people in a project group as software development
essential that we can trust that software. □ Scale □ Software has to be developed across a very wide range of scales, from very small embedded previously. □ Normally described from 3 perspectives □ A dynamic perspective that shows phases over time; □ A static perspective that shows involves diverse activities such as negotiating with clients, programming, testing and documentation. The group organization □ A group should be
systems in portable or wearable devices through to Internet-scale, cloud-based systems that serve a global community. 28 Software engineering process activities; □ A practive perspective that suggests good practice. 54 Phases in the Rational Unified Process Phase iteration Elaboration organized so that individuals can contribute to the best of their abilities and tasks can be completed as expected. □ Technical and managerial
diversity □ There are many different types of software system and there is no universal set of software techniques that is applicable to all of these. Inception Construction Transition RUP phases □ Inception □ Establish the business case for the system. □ Elaboration □ Develop an communications □ Good communications between group members, and etween the software engineering team and other 58 Selecting group
□ The software engineering methods and tools used depend on □ the type of application being developed □ the requirements of the customer and understanding of the problem domain and the system architecture. □ Construction □ System design, programming and testing. □ Transition □ members □ A manager or team leader's job is to create a cohesive group and organize their group so that they can work together effectively. □ This
□ the background of the development team. 29 Application types Stand-alone applications □ These are application systems that run on a local Deploy the system in its operating environment. RUP iteration In-phase iteration □ Each phase is incrementally. iterative with results developed involves creating a group with the right balance of technical skills and personalities, and organizing that group so that the members work together
computer, such as a PC. They include all necessary functionality and do not need to be connected to a network. Interactive transaction-based Cross-phase iteration □ As shown by the loop in the RUP model, the whole set of phases may be enacted incrementally. 57 Source : effectively. 59 Assembling a team May not be possible to appoint the ideal people to work on a project □ Project budget may not allow for the use
applications □ Applications that execute on a remote computer and are accessed by users from their own PCs or terminals. These include web http://www.ibm.com 58 Static workflows in the Rational Unified Process Workflow Description Business modelling The business processes are of highly-paid staff; □ Staff with the appropriate experience may not be available; □ An organisation may wish to develop employee skills on a
applications such as e-commerce applications. Embedded control systems □ These are software control systems that control and manage modelled using business use cases. Requirements Actors who interact with the system are identified and use cases are developed to model the software project. Managers have to work within these constraints especially when there are shortages of trained staff. 60 Group composition □
hardware devices . Numerically, there are probably more embedded systems than any other type of system 30 Application types Batch processing system requirements. Analysis and design A design model is created and documented using architectural models, component models, object Group composed of members who share the same motivation can be problematic □ Task-oriented - everyone wants to do their own thing; □ Self-
systems □ These are business systems that are designed to process data in large batches. They process large numbers of individual inputs to models and sequence models. Implementation The components in the system are implemented and structured into implementation sub-systems. oriented - everyone wants to be the boss; □ Interaction-oriented - too much chatting, not enough work. □ An effective group has a balance of all
create corresponding outputs. Entertainment systems □ These are systems that are primarily for personal use and which are intended to entertain Automatic code generation from design models helps accelerate this process. 59 Static workflows in the Rational Unified Process Workflow types. □ This can be difficult to achieve software engineers are often task-oriented. □ Interaction-oriented people are very important as theycan
the user. Systems for modeling and simulation □ These are systems that are developed by scientists and engineers to model physical processes or Description Testing Testing is an iterative process that is carried out in conjunction with implementation. System testing follows the completion of detect and defuse tensions that arise. Group organization □ The way that a group is organized affects □ the decisions that are made by that group,
situations, which include many, separate, interacting objects. 31 Application types Data collection systems □ These are systems that collect data the implementation. Deployment A product release is created, distributed to users and installed in their workplace. Configuration and change □ the ways that information is exchanged and □
from their environment using a set of sensors and send that data to other systems for processing. Systems of systems □ These are systems that management This supporting workflow managed changes to the Project This supporting workflow manages the system management development
are composed of a number of other software systems. Software engineering fundamentals Some fundamental principles apply to all types of Environment This workflow is concerned with making appropriate RUP good practice □ Develop software iteratively □ Plan increments based on
software system, irrespective of the development techniques used: □ Systems should be developed using a managed and understood customer priorities and deliver highest priority increments first. □ Manage requirements □ Explicitly document customer requirements and keep
development process. Of course, different processes are used for different types of software. □ Dependability and performance are important for all track of changes to these requirements. □ Use component-based architectures □ Organize the system architecture as a set of reusable
types of system. □ Understanding and managing the software specification and requirements are important. □ Where appropriate, you should components. 61 RUP good practice □ Visually model software □ Use graphical UML models to present static and dynamic views of the software. □
reuse software that has already been developed rather than write new software. 4. Software engineering ethics 37 Software engineering ethics Verify software quality □ Ensure that the software meet's organizational quality standards. □ Control changes to software □ Manage software
Software engineering involves wider responsibilities than simply the application of technical skills. Software engineers must behave in an honest changes using a change management system and configuration management tools. WEEK 3: PROJECT MANAGEMENT Software project
and ethically responsible way if they are to be respected as professionals. Ethical behaviour is more than simply upholding the law but involves management □ Concerned with activities involved in □ ensuring that software is delivered on time and on schedule and □ accordance with the
following a set of principles that are morally correct. 38 Issues of professional responsibility Confidentiality □ Engineers should normally respect the requirements of the organisations developing and □ procuring the software. □ Is needed because ... □ software development is always subject to
confidentiality of their employers or clients irrespective of whether or not a formal confidentiality agreement has been signed. Competence □ budget and schedule constraints that are set by the organisation developing the software. Good management cannot guarantee project success.
Engineers should not misrepresent their level of competence. They should not knowingly accept work which is outwith their competence. 39 Issues ement usually results in project 3 Success criteria □ Important goals for most projects: □ Deliver the software to the customer at the agreed time. □
of professional responsibility Intellectual property rights □ Engineers should be aware of local laws governing the use of intellectual property such Keep overall costs within budget. □ Deliver software that meets the customer’s expectations. □ Maintain a happy and well-functioning development
as patents, copyright, etc. They should be careful to ensure that the intellectual property of employers and clients is protected. □ Computer misuse team. 4 Software management distinctions The product is intangible. □ Software cannot be seen or touched. Many software projects are 'one-off
□ Software engineers should not use their technical skills to misuse other people's computers. Computer misuse ranges from relatively trivial projects. □ Large software projects are usually different in some ways from previous projects. Software processes are variable and
(game playing on an employer's machine, say) to extremely serious (dissemination of viruses). Ethical principles 1. PUBLIC - Software engineers organizationspecific. □ We still cannot reliably predict when a particular software process is likely to lead to development problems. 5 Factors
shall act consistently with the public interest. 2. CLIENT AND EMPLOYER - Software engineers shall act in a manner that is in the best interests of influencing project management Company size Software customers Software size Software type Organizational culture Software development
their client and employer consistent with the public interest. 3. PRODUCT - Software engineers shall ensure that their products and related processes These factors mean that project managers in different organizations may work in quite different ways. 6 Universal management
modifications meet the highest professional standards possible. 4. JUDGMENT - Software engineers shall maintain integrity and independence in activities Project planning □ Project managers are responsible for planning, estimating and scheduling project development and assigning people
their professional judgment. 5. MANAGEMENT - Software engineering managers and leaders shall subscribe to and promote an ethical approach to tasks. Reporting □ Project managers are usually responsible for reporting on the progress of a project to customers and to the managers of the
to the management of software development and maintenance. 6. PROFESSION - Software engineers shall advance the integrity and reputation company developing the software. Proposal writing □ Project managers write a proposal to win a contract to carry out an item of work. The
of the profession consistent with the public interest. 7. COLLEAGUES - Software engineers shall be fair to and supportive of their colleagues. 8. proposal describes the objectives of the project and how it will be carried out. 7 Universal management activities □ Risk management □ Project
SELF - Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to managers assess the risks that may affect a project, monitor these risks and take action when problems arise. □ People management □ Project
the practice of the profession. 43 cdi„ How projects really work ? How the analyst designed it How the customer explained it Howthe programmer managers have to choose people for their team and establish ways of working that leads to effective team performance. 8 1. Project planning One
wrote it How the project leader understood it ctcartoon.com How the business consultant described it What operations installed How the customer of the most important jobs of a software project manager. Project planning involves □ break down the work into parts and assign these to project
was billed How the project was documented WWW projectcartoon com What the customer I really needed How it was supported WEEK 2: team members, □ anticipate problems that might arise and prepare tentative solutions to those problems. The project plan □ created at the start of
SOFTWARE PROCESSES What is a process? □ Four activities that are fundamental to software engineering? □ What is process model? The a project, □ used to communicate how the work will be done to the project team and customers, and to help assess progress on the project. 10
software process A structured set of activities required to develop a software system. 4 fundamental activities: □ Specification - defining what the Planning stages At the proposal stage □ when you are bidding for a contract to develop or provide a software system. During the project startup
system should do; □ Design and implementation - defining the organization of the system and implementing the system; □ Validation - checking phase □ 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
that it does what the customer wants; □ Evolution - changing the system in response to changing customer needs. A software process model □ Is across your company, etc. Periodically throughout the project □ when you modify your plan in the light of experience gained and information from
an abstract representation of a process. □ Presents a description of a process from some particular perspective. 4 Software process descriptions □ monitoring the progress of the work. 11 Proposal planning □ Planning may be necessary with only outline software requirements. □ Goal: to
When we describe and discuss processes, we usually talk about □ the activities in these processes such as specifying a data model, designing a provide information that will be used in setting a price for the system to customers. □ Project pricing involves □ estimating how much the software
user interface, etc. and □ the ordering of these activities. □ Process descriptions may also include: □ □ Products, which are the outcomes of a will cost to develop, □ taking factors such as staff costs, hardware costs, software costs, etc. into account. 12 Project startup planning □ Know
process activity; Roles, which reflect the responsibilities of the people involved in the process; Pre- and post-conditions, which are statements that more about the system requirements but do not have design or implementation information. □ Create a plan with enough detail to make decisions
are true before and after a process activity has been □ n ted or a product produced. Plan-driven and agile processes □ Plan-driven processes are about the project budget and staffing. □ This plan is the basis for project resource allocation □ The startup plan should also define project
processes where all of the process activities are planned in advance and progress is measured against this plan. □ In agile processes, planning is monitoring mechanisms. □ Keep track of the progress and □ Compare actual and planned progress and costs. □ A startup plan is still needed for
incremental and it is easier to change the process to reflect changing customer requirements. □ In practice, most practical processes include agile development to allow resources to be allocated to the project. 13 cdi» Development planning The project plan should be regularly amended
elements of approaches. □ There are no right or wrong software processes. both plan-driven and agile 6 1. Software process models 7 □ The as the project progresses and you know more about the software and its development The project schedule, cost-estimate and risks have to be
waterfall model □ Plan-driven model. Separate and distinct phases of specification and development. □ Incremental development □ Specification, regularly revised. 14 The project planning process 15 Project scheduling 16 Project scheduling Is the process of deciding how the work in a project
development and validation are interleaved. May be plan-driven or agile. □ Reuse-oriented software engineering □ The system is assembled from will be organized as separate tasks, and when and how these tasks will be executed. Estimate the calendar time needed to complete each task,
existing components. May be plan-driven or agile. In practice, most large systems are developed usin process that incorporates elements from the effort required and who will work on the tasks that have been identified. Estimate the resources needed to complete each task, the time
models. The waterfall model 9 Waterfall model phases □ The main drawback of the waterfall model is the difficulty of accommodating change after required on specialized hardware, and what the travel budget will be. 17 Project scheduling activities □ Split project into tasks and estimate time
the process is underway. □ In principle, a phase has to be complete before moving onto the next phase. in-Fo Waterfall model problems Inflexible and resources required to complete each task. □ Organize tasks concurrently to make optimal use of workforce. □ Minimize task dependencies to
partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements ConS . □ Only appropriate when the avoid delays caused by one task waiting for another to complete. □ Dependent on project managers intuition and experience. 18 The project
requirements are well-understood and changes will be fairly limited during the design process. □ Few business systems have stable requirements. scheduling process Software requirements Bar charts describing the project schedule and design information 19 Scheduling problems Estimating
Mostly used for large systems engineering projects where a system is developed at several sites. □ The plan-driven nature of the waterfall model 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
helps coordinate the work. An important variant of the waterfall model is formal system development □ □ □ Use a mathematical model to specify a task. Adding people to a late project makes it later because of communication overheads. The unexpected always happens. Always allow
system. Use mathematical transformations that preserve its consistency, into executable code. Mathematical transformations are correct: a contingency in planning. 20 Schedule presentation Use graphical notations to illustrate the project schedule. □ These show the project breakdown
program generated in this way is consistent with its specification. □ Formal development processes (B method for example) are suited to the into tasks. □ Tasks should not be too small. They should take about a week or two. Calendar-based □ Bar charts (Gantt charts) are the most
development of systems that have stringent safety, reliability, or security requirements. Incremental development Concurrent activities Outline commonly used representation for project schedules. □ They show who is responsible for each activity, the expected elapsed time, and when the
description 13 Incremental development benefits The cost of accommodating changing customer requirements is reduced □ The amount of activity is scheduled to begin and end. Activity networks □ Are network diagrams, Show task dependencies 21 H cdw Project activities □ Project
analysis and documentation that has to be redone is much less than is required with the Waterfall model. It is easier to get customer feedback on activities (tasks) are the basic planning element. Each activity has: □ a duration in calendar days or months, □ an effort estimate, which shows the
the development work that has been done. pros □ Customers can comment on demonstrations of the software and see how much has been number of person-days or person-months to complete the work, □ a deadline by which the activity should be complete, □ a defined end-point,
implemented. More rapid delivery and deployment of useful software to the customer is possible. pros □ Customers are able to use and gain value which might be a document, the holding of a review meeting, the successful execution of all tests, etc. 22 Milestones and deliverables □ Milestones
from the software earlier than is possible with a waterfall process. 14 Incremental development problems □ The process is not visible- tons □ are stages in the project where a progress assessment can be made. □ Deliverables are work products that are delivered to the customer, e.g. a
Managers need regular deliverables to measure progress. If systems are developed quickly, it is not cost-effective to produce documents that requirements document for the system. Staff allocation chart Estimation techniques □ Organizations need to make software effort and cost
reflect every version of the system. □ System structure tends to degrade as new increments are added, cans □ Unless time and money is spent on estimates. □ Experience-based techniques □ The estimate is based on the manager’s experience of past projects and the application domain. □
refactoring to improve the software, regular change tends to corrupt its structure. Incorporating further software changes becomes increasingly The manager makes an informed judgment of what the effort requirements are likely to be. □ Algorithmic cost modeling □ A formulaic approach is
difficult and costly. 15 Integration and configuration Based on systematic reuse where systems are integrated from existing components or COTS used to compute the project effort based on estimates of product attributes, such as size, and process characteristics, such as experience of 28
(Commercial-off-the-shelf) systems. lafc Reused elements may be configured to adapt their behaviour and functionality to a user's requirements Estimate uncertainty 29 Risk management Risk management is concerned with identifying risks and drawing up plans to minimise their effect on a
Reuse is now the standard approach for building many types of business system in-fo 16 Types of reusable software □ Stand-alone application project. Software risk management is important because of the inherent uncertainties in software development. □ These uncertainties stem from
systems (sometimes called COTS) that are configured for use in a particular environment. □ Collections of objects that are developed as a loosely defined requirements, requirements changes due to changes in customer needs, difficulties in estimating the time and resources required
package to be integrated with a component framework such as .NET or J2EE. □ Web services that are developed according to service standards for software development, and differences in individual skills. You have to anticipate risks, understand the impact of these risks on the project, the
and which are available for remote invocation. 17 Reuse-oriented software engineering Advantages and drawbacks □ Advantages □ Reduced product and the business, and take steps to avoid these risks. 30 Risk classification □ There are two dimensions of risk classification □ The type of
costs and risks as less software is developed from scratch □ Faster delivery and deployment of system □ Drawbacks □ requirements compromises risk (technical, organizational, ..) □ what is affected by the risk □ Project risks affect schedule or resources; □ Product risks affect the quality or
are inevitable ■ this may lead to a system that does not meet the real needs of users. □ Loss of control over evolution of reused system elements performance of the software being developed; □ Business risks affect the organisation developing or procuring the software. 31 Examples of
19 20 2. Process activities Real software processes are interleaved sequences of technical, collaborative and managerial activities with the overall common project, product, and business risks Risk Affects Description 1 Staff turnover Project Experienced staff will leave the project before it is
goal of specifying, designing, implementing and testing a software system. The four basic process activities of specification, development, finished. Management change Project There will be a change of organizational management with different priorities. Hardware unavailability
validation and evolution are organized differently in different development processes. For example: □ In the waterfall model, they are organized in Project Hardware that is essential for the project will not be delivered on schedule. Requirements change Project and product There will be a larger
sequence, □ In incremental development, they are interleaved. 21 Software specification The process of establishing what services are required number of changes to the requirements than anticipated. Specification delays Project and product Specifications of essential interfaces are not
and the constraints on the system's operation and development. Requirements engineering process □ Feasibility study: Is it technically and available on schedule. Size underestimate Project and product The size of the system has been underestimated. CASE tool underperformance
financially feasible to build the system? □ Requirements elicitation and analysis: What do the system stakeholders require or expect from the Product CASE tools, which support the project, do not perform as anticipated. Technology change Business The underlying technology on which
system? □ Requirements specification: Defining the requirements in detail □ Requirements validation: Checking the validity of the requirements 22 the system is built is superseded by new technology. Product competition Business A competitive product is marketed before the system is
L The requirements engineering process Requirements document Software design and implementation The process of converting the system completed. Risk management process □ Risk identification □ Identify project, product and business risks; □ Risk analysis □ Assess the likelihood
specification into an executable system. Software design □ Design a software structure that realises the specification; Implementation □ Translate and consequences of these risks; □ Risk planning □ Draw up plans to avoid or minimise the effects of the risk; □ Risk monitoring □ Monitor the
this structure into an executable program; The activities of design and implementation are closely related and may be inter-leaved. 24 A general risks throughout the project; 33 Risk management process V V V List of potential risks Prioritized risk list V Risk avoidance and contingency plans
model of the design process Design inputs Platform information Requirements specification Data description Design activities Design outputs Risk assessment 34 Risk identification □ May be a team activities or based on the individual project manager's experience. □ A checklist of
System architecture — Database specification Interface specification — Component specification — 25 Design activities Architectural design, common risks may be used to identify risks in a project □ Technology risks. □ People risks. □ Organisational risks. □ Tools risks. □ Requirements
where you identify □ the overall structure of the system, □ the principal components, their relationships and how they are distributed. Interface risks. □ Estimation risks. 35 Examples of different risk types Risk type Possible risks Technology The database used in the system cannot process
design □ define the interfaces between system components. Component selection and design □ where you search for reusable components. If as many transactions per second as expected. (1) Reusable software components contain defects that mean they cannot be reused as planned.
unavailable, you design how it will operate. Database design □ design the system data structures and how these are to be represented in a (2) People It is impossible to recruit staff with the skills required. (3) Key staff are ill and unavailable at critical times. (4) Required training for staff is
database. 26 System implementation The software is implemented either by developing a program or programs or by configuring an application not available. (5) Organizational The organization is restructured so that different management are responsible for the project. (6) Organizational
system. Design and implementation are interleaved activities for most types of software system. Programming is an individual activity with no financial problems force reductions in the project budget. (7) Tools The code generated by software code generation tools is inefficient. (8)
standard process. Debugging is the activity of finding program faults and correcting these faults. 27 Software validation Verification and validation Software tools cannot work together in an integrated way. (9) Requirements Changes to requirements that require major design rework are
(V & V) is intended to show that a system conforms to its specification and meets the requirements of the system customer. Involves checking and proposed. (10) Customers fail to understand the impact of requirements changes. (11) Estimation The time required to develop the software is
review processes and system testing. System testing involves executing the system with test cases that are derived from the specification of the underestimated. (12) The rate of defect repair is underestimated. (13) The size of the software is underestimated. (14) 36 Risk analysis □ Assess
real data to be processed by the system. Testing is the most commonly used V & V activity. 28 Stages of testing 29 Testing stages □ Development probability and seriousness of each risk. □ Probability may be very low, low, moderate, high or very high. □ Risk consequences might be
or component testing □ Individual components are tested independently; □ Components may be functions or objects or coherent groupings of catastrophic, serious, tolerable or insignificant. 37 Risk types and examples Risk Probability Effects Organizational financial problems force
these entities. □ System testing □ Testing of the system as a whole. Testing of emergent properties is particularly important. □ Acceptance testing □ reductions in the project budget (7). Low Catastrophic It is impossible to recruit staff with the skills required for the project (3). High Catastrophic
Testing with customer data to check that the system meets the customer's needs. 30 Testing phases in a plan-driven software process Key staff are ill at critical times in the project (4). Moderate Serious Faults in reusable software components have to be repaired before these
Requirements specification System specification System design Acceptance test plan System integration test plan Service Acceptance test components are reused. (2). Moderate Serious Changes to requirements that require major design rework are proposed (10). Moderate Serious
Detailed design System integration test Sub-system integration test plan Sub-system integration test Module and unit code and test Software The organization is restructured so that different management are responsible for the project (6). High Serious The database used in the system
evolution Software is inherently flexible and can change. As requirements change through changing business circumstances, the software that cannot process as many transactions per second as expected (1). Moderate Serious Risk types and examples Risk Probability Effects The time
supports the business must also evolve and change. Although there has been a demarcation between development and evolution this is required to develop the software is underestimated (12). High Serious Software tools cannot be integrated (9). High Tolerable Customers fail to
increasingly irrelevant as fewer and fewer systems are completely new. 32 System evolution 33 34 3. Coping with change □ Change is inevitable in understand the impact of requirements changes (11). Moderate Tolerable Required training for staff is not available (5). Moderate Tolerable The
all large software projects. □ Business changes lead to new and changed system requirements □ New technologies open up new possibilities for rate of defect repair is underestimated (13). Moderate Tolerable The size of the software is underestimated (14). High Tolerable Code generated by
improving implementations □ Changing platforms require application changes □ Change leads to rework so the costs of change include both code generation tools is inefficient (8). Moderate Insignificant 39 Risk planning □ Consider each risk and develop a strategy to manage that risk. □
rework as well as the costs of implementing new functionality 35 Reducing the costs of rework □ Change anticipation (Change avoidance) □ The Avoidance strategies □ The probability that the risk will arise is reduced; □ Minimisation strategies □ The impact of the risk on the project or product
software process includes activities that can anticipate possible changes before significant rework is required. □ Example: a prototype system may will be reduced; □ Contingency plans □ If the risk arises, contingency plans are plans to deal with that risk; Strategies to help manage risk Risk
be developed to show some key features of the system to customers. □ Change tolerance □ The process is designed so that changes can be Strategy Organizational financial problems Prepare a briefing document for senior management showing how the project is making a very
accommodated at relatively low cost. □ This involves some form of incremental development. 36 Coping with changing requirements □ System important contribution to the goals of the business and presenting reasons why cuts to the project budget would not be cost-effective. Recruitment
prototyping □ A version of the system or part of the system is developed quickly to check the customer’s requirements and the feasibility of design problems Alert customer to potential difficulties and the possibility of delays; investigate buying-in components. Staff illness Reorganize team so
decisions. □ This approach supports change anticipation. □ Incremental delivery □ System increments are delivered to the customer for comment that there is more overlap of work and people therefore understand each other’s jobs. Defective components Replace potentially defective
and experimentation. □ This supports both change avoidance and change tolerance. 37 Software prototyping □ A prototype is an initial version of a components with bought-in components of known reliability. Requirements changes Derive traceability information to assess requirements change
system used to demonstrate concepts and try out design options. □ A prototype can be used in: □ The requirements engineering process to help impact; maximize information hiding in the design. Strategies to help manage risk Risk Strategy Organizational restructuring Prepare a briefing
(e.g., authentication) can be provided in each layer to increase the dependability of the system. Disadvantages □ In practice, providing a clean fill-in Simple data entry Easy to learn Checkable Command Powerful and flexible language Natural Accessible to casual language users Easily testing Part of release testing may involve testing the emergent properties of a system, such as performance and reliability. Tests should reflect the
separation between layers is often difficult and a high-level layer may have to interact directly with lower-level layers rather than through the layer extended Main disadvantages May be hard to implement. Only suitable where there is a visual metaphor for tasks and objects. Slow for profile of use of the system. Performance tests usually involve planning a series of tests where the load is steadily increased until the system
immediately below it. □ Performance can be a problem because of multiple levels of interpretation of a service request as it is processed at each experienced users. Can become complex if many menu options. Takes up a lot of screen space. Causes problems where user options do not performance becomes unacceptable. Stress testing is a form of performance testing where the system is deliberately overloaded to test its failure
layer. processed by many layers Repository architecture □ Sub-systems must exchange data. This may be done in two ways: □ Shared data is match the form fields. Hard to learn. Poor error management. Requires more typing. Natural language understanding systems are unreliable. behaviour. 4. USER TESTING Users or customers provide input and advice on system testing. Is essential, even when comprehensive system and
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 Application examples Video games CAD systems Most generalpurpose systems Stock control, Personal loan processing Operating systems, 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
explicitly to other sub-systems. □ When large amounts of data are to be shared, the repository model of sharing is most commonly used a this is an Command and control systems Information retrieval systems ChatGPT Information presentation Is concerned with presenting system information reliability, performance, usability and robustness of a system. These cannot be replicated in a testing environment. 55 Types of user testing Alpha
efficient data sharing mechanism. Repository pattern ► Description □ All data in a system is managed in a central repository that is accessible to to system users. The information may be □ presented directly (e.g. text in a word processor) □ or transformed in some way for presentation (e.g. in 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
all system components. □ Components do not interact directly, only through the repository. ► Used when □ You have a system in which large some graphical form). The Model-View-Controller approach is a way of supporting multiple presentations of data. 19 ► Static information □ is made available to users to allow them to experiment and to raise problems that they discover with the system developers. Acceptance testing □
volumes of information are generated that has to be stored for a long time. □ You may also use it in data-driven systems where the inclusion of Initialised at the beginning of a session. It does not change during the session. □ May be either numeric or textual. ► Dynamic information □ Customers test a system to decide whether or not it is ready to be accepted from the system developers and deployed in the customer
data in the repository triggers an action or tool. ► Advantages □ □ □ Components can be independent—they do not need to know of the existence Changes during a session and the changes must be communicated to the system user. □ May be either numeric or textual. Information display environment. Primarily for Agile methods and acceptance testing The user/customer is part of the development team and is responsible for making
of other components. Changes made by one component can be propagated to all components. All data can be managed consistently (e.g., factors Is the user interested in precise information or data relationships? How quickly do information values change? Must the change be 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
backups done at the same time) as it is all in one place. ► Disadvantages □ The repository is a single point of failure so problems in the repository indicated immediately? Must the user take some action in response to a change? Is there a direct manipulation interface? Is the information textual automatically when changes are made. There is no separate acceptance testing process. Main problem here is whether or not the embedded user
affect the whole system. □ May be inefficiencies in organizing all communication through the repository. □ Distributing the repository across several or numeric? Are relative values important? 23 Alternative information presentations • Digital presentation • Compact - takes up little screen Jan Feb is 'typical' and can represent the interests of all system stakeholders. WEEK 10: AGILE SOFTWARE DEVELOPMENT 1. Agile methods Extreme
computers may be Client-server architecture □ Distributed system model which shows how data and processing is distributed across a range of Mar April May June 2842 2851 3164 2789 1273 2835 space; • Precise values can be communicated. Analogue presentation • Easier to get an 'at a programming Agile project management Scaling agile methods 2 Topics covered 1. 2. 3. 4. Agile methods Extreme programming Agile project
components. □ Can be implemented on a single computer. □ Set of stand-alone servers which provide specific services. □ Set of clients which call glance' 4000 -1 impression of a value; Possible to show relative values; Easier to see exceptional data 0 values. 3000- 2000- 1000- May June 24 management Scaling agile methods 3 Rapid software development and it is software Rapid development and delivery is now often the most
on these services. Network which allows clients to access servers. Client-server pattern Description □ In a client-server architecture, the Colour displays Colour adds an extra dimension to an interface and can help the user understand complex information structures. Colour can be important requirement for software systems □ Businesses operate in a fast - changing requirement practically impossible to produce a set of stable
functionality of the system is organized into services, with each service delivered from a separate server. □ Clients are users of these services and used events. Common mistakes in interface design include: to highlight exceptional the use of colour in should not create an alert with green color requirements □ Software has to evolve quickly to reflect changing needs. business Plan-driven development is essential for some types of system
access servers to make use of them. Used when □ □ Data in a shared database has to be accessed from a range of locations Load on a system is □ The use of colour to communicate meaning; □ The over-use of colour in the display. Colour use guidelines Limit the number of colours used and but does not meet these business needs. Agile development methods emerged in the late 1990s whose aim was to radically reduce the delivery
variable. ► Advantages □ Servers can be distributed across a network. □ General functionality can be available to all clients and does not need to be conservative in their use. Use colour change to show a change in system status. Use colour coding to support the task that users are trying to time for working software systems 4 Agile development Program specification, design and implementation are inter-leaved increments
be implemented by all services. ► Disadvantages □ Each service is a single point of failure service attacks or server failure so susceptible □ perform. Use colour coding in a thoughtful and consistent way. Be careful about colour pairings. Error messages Error message design is critically stakeholders involved in version !!initial and release states. with feedback in betweens The system is developed as a series of versions or with
Performance may be unpredictable because it depends on the network as well as the system. □ May be management problems if servers are important. □ Poor error messages can mean that a user rejects rather than accepts a system. Messages should be polite, concise, consistent and specification and evaluation Frequent delivery of new versions for evaluation Extensive tool support (e.g. automated testing tools) used to support
owned by different organizations. Pipe and filter architecture □ Functional transformations process their inputs to produce outputs. □ May be constructive. The background and experience of users should be the determining factor in message design Design factors in message wording development. Minimal documentation - focus on working code Plan-driven and agile development Plan-driven development □ □ A plan-driven
referred to as a pipe and filter model. □ Variants of this pattern are very common. When transformations are sequential, this is a batch sequential Factor Description Context Wherever possible, the messages generated by the system should reflect the current user context. As far as is approach to software engineering is based around separate development stages with the outputs to be produced at each of these stages planned
model which is extensively used in data processing systems. □ Not really suitable for interactive systems. Pipe and filter pattern Description □ The possible, the system should be aware of what the user is doing and should generate messages that are relevant to their current activity. in advance. plan-driven, Not necessarily waterfall model incremental development is possible Iteration occurs within activities. □ Agile development
processing of the data in a system is organized so that each processing component (filter) is discrete and carries out one type of data Experience As users become familiar with a system they become irritated by long, ‘meaningful’ messages. However, beginners find it difficult to □ Specification, design, implementation and testing are inter-leaved and the outputs from the development process are decided through a process
transformation. □ The data flows (as in a pipe) from one component to another for processing. Used when □ Commonly used in data processing understand short terse statements of a problem. You should provide both types of message and allow the user to control message conciseness. of negotiation during the software development process. Agile and plan-driven methods Most projects include elements of plan-driven and agile
applications (both batch- and transaction-based) where inputs are processed in separate stages to generate related outputs. Pipe and filter pattern Skill level Messages should be tailored to the user’s skills as well as their experience. Messages for the different classes of user may be expressed processes. Deciding on the balance depends on: □ Is it important to have a very detailed specification and design before moving to
Advantages □ □ Easy to understand and supports transformation reuse.? Workflow style matches the structure of many business processes. in different ways depending on the terminology that is familiar to the reader. Style Messages should be positive rather than negative. They should implementation? If so, you probably need to use a plan-driven approach. □ □ Is an incremental delivery strategy, where you deliver the software to
Evolution by adding transformations is straightforward. Can be implemented as either a sequential or concurrent system. existing, happening, or use the active rather than the passive mode of address. They should never be insulting or try to be funny. Culture Wherever possible, the designer customers and get rapid feedback from them, realistic? If so, consider using agile methods. How large is the system that is being developed? Agile
done at the same time. □ Disadvantages □ The format for data transfer has to be agreed upon between communicating transformations. si ole's □ of messages should be familiar with the culture of the country where the system is sold. There are distinct cultural differences between Europe, methods are most effective when the system can be developed with a small co-located team who can communicate informally. This may not be
Each transformation must parse its input and unparse its output to the agreed form. This increases system overhead and may mean that it is Asia and America. A suitable message for one culture might be unacceptable in another. 32 User error Assume that a nurse misspells the name of possible for large systems that require larger development teams so a plan-driven approach may have to be used. Agile methods Dissatisfaction
impossible to reuse functional transformations that use incompatible data structures 4. Application architectures □ Application systems are a patient whose records he is trying to retrieve. Please type the patients name in the box then click on OK Patients name MacDonald, R. 2. User with the overheads involved in software design methods of the 1980s and 1990s led to the creation of agile methods. These methods: □ Focus on
designed to meet an organizational need. □ As businesses have much in common □ their application systems also tend to have a common interface design process UI design process UI design is an iterative process involving close liaisons between users and designers. □ The 3 core the code rather than the design □ Are based on an iterative approach to software development □ Are intended to deliver working software quickly
architecture that reflects the application requirements. □ A generic application architecture is an architecture for a type of software system that may activities in this process are: □ User analysis. Understand what the users will do with the system; □ System prototyping. Develop a series of and evolve this quickly to meet changing requirements. The aim of agile methods is to reduce overheads in the software process (e.g. by limiting
be configured and adapted to create a system that meets specific requirements. Use of application architectures □ As a starting point for prototypes for experiment; □ Interface evaluation. Experiment with these prototypes with users. 3. User analysis User analysis If you don't documentation) and to be able to respond quickly to changing requirements without excessive rework. Agile manifesto □ We are uncovering better
architectural design. □ As a design checklist. □ As a way of organizing the work of the development team. □ As a means of assessing components understand what the users want to do with a system, you have no realistic prospect of designing an effective interface. User analyses have to be ways of developing software by doing it and helping others do it. Through this work we have come to value: □ Individuals and interactions over
for reuse. □ As a vocabulary for talking about application types. 47 Examples of application types □ Data processing applications □ Data driven described in terms that users and other designers can understand. Scenarios where you describe typical episodes of use, are one way of processes and tools □ Working software over comprehensive documentation □ Customer collaboration over contract negotiation □ Responding to
applications that process data in batches without explicit user intervention during the processing. □ Transaction processing applications □ Data- describing these analyses. Requirements from the scenario Users may not be aware of appropriate search terms so need a way of helping them change over following a plan □ That is, while there is value in the items on the right, we value the items on the left more. The principles of agile
centered applications that process user requests and update information in a system database. □ Event processing systems □ Applications where choose terms. Users have to be able to select collections to search. Users need to be able to carry out searches and request copies of relevant methods Principle Description Customer involvement Incremental delivery People not process Embrace change Customers should be closely
system actions depend on interpreting events from the system's environment. □ Language processing systems □ Applications where the users' material. 41 Analysis techniques Task analysis □ Models the steps involved in completing a task. ►Interviewing and questionnaires □ Asks the involved throughout the development process. Their role is provide and prioritize new system requirements and to evaluate the iterations of the
intentions are specified in a formal language that is processed and interpreted by the system. Application type examples □ Focus here is on users about the work they do. ►Ethnography □ Observes the user at work. Interviewing Design semi-structured interviews based on open- ended system. The software is developed in increments with the customer specifying the requirements to be included in each increment. The skills of the
transaction processing and language processing systems. □ Transaction processing systems □ E-commerce systems; □ Reservation systems. □ questions. Users can then provide information that they think is essential; not just information that you have thought of collecting. Group interviews development team should be recognized and exploited. Team members should be left to develop their own ways of working without prescriptive
Language processing systems □ Compilers; □ Command interpreters Transaction processing systems □ □ □ Process user requests for information or focus groups allow users to discuss with each other what they do. Ethnography Involves an external observer watching users at work and processes. Expect the system requirements to change and so design the system to accommodate these changes. Maintain simplicity Focus on
from a database or requests to update the database. From a user perspective, a transaction is: □ Any coherent sequence of operations that questioning them in an unscripted way about their work. Valuable because many user tasks are intuitive and they find these very difficult to simplicity in both the software being developed and in the development process. Wherever possible, actively work to eliminate complexity from the
satisfies a goal; □ For example - find the times of flights from London to Paris. Users make asynchronous requests for service which are then describe and explain. Also helps understand the role of social and organisational influences on work. 4. User interface prototyping The aim of system. Agile principles and organizational practice Principle Practice Customer involvement Embrace change Incremental delivery This depends
processed by a transaction manager. Information systems architecture □ Information systems have a generic architecture that can be organized as prototyping is to allow users to gain direct experience with the interface. Without such direct experience, it is impossible to judge the usability of an on having a customer who is willing and able to spend time with the development team and who can represent all system stakeholders. Often,
a layered architecture. □ These are transaction-based systems as interaction with these systems generally involves database transactions. □ interface. Prototyping may be a two-stage process: □ Early in the process, paper prototypes may be used; □ The design is then refined and customer representatives have other demands on their time and cannot play a full part in the software development. Where there are external
Layers include: □ The user interface □ User communications □ Information retrieval □ System database Web-based information systems increasingly sophisticated automated prototypes are then developed. Paper prototyping ►Work through scenarios using sketches of the interface stakeholders, such as regulators, it is di
Information and resource management systems are now usually web-based systems □ user interfaces are implemented using a web browser. ►Use a storyboard to present a series of interactions with the system. ►Paper prototyping is an effective way of getting user reactions to a design
Example: □ E-commerce systems are Internet-based resource management systems that accept electronic orders for goods or services and then proposal. Prototyping techniques Script-driven prototyping □ Develop a set of scripts and screens using a tool such as Macromedia Director. When
arrange delivery of these goods or services to the customer. □ In an e-commerce system, the application-specific layer includes additional the user interacts with these, the screen changes to the next display. Visual programming □ Use a language designed for rapid development such
functionality supporting a ‘shopping cart' in which users can place a number of items in separate transactions, then pay for them all together in a as Visual Basic. Internet-based prototyping □ Use a web browser and associated scripts. 5. Interface evaluation □ Some evaluation of a user
single ction. Server implementation □ These systems are often implemented as multi-tier client server/architectures □ The web server is interface design should be carried out to assess its suitability. Full scale evaluation is very expensive and impractical for most systems. Ideally, an
responsible for all user communications, with the user interface implemented using a web browser; □ The application server is responsible for interface should be evaluated against a usability specification. However, it is rare for such specifications to be produced. Usability attributes
implementing application-specific logic as well as information storage and retrieval requests; □ The database server moves information to and from Attribute Learnability Speed of operation Description How long does it take a new user to become productive with the system? How well does the
the database and handles transaction management WEEK 7: OBJECT-ORIENTED DESIGN Design and implementation Software design and system response match the user’s work practice? an accountant would hate slow calculation time Robustness Recoverability Adaptability How
implementation is the stage in the software engineering process at which an executable software system is developed. Software design and tolerant is the system of user error? How good is the system at recovering from user errors? How closely is the system work? tied to a single
implementation activities are invariably inter-leaved. □ Software design is a creative activity in which you identify software components and their model of 54 Simple evaluation techniques Questionnaires for user feedback. Video recording of system use and subsequent tape evaluation.
relationships, based on a customer's requirements. □ Implementation is the process of realizing the design as a program. 1. Object-oriented design Instrumentation of code to collect information about facility use and user errors. The provision of code in the software to collect on-line user
using the UML Object-oriented development Object-oriented analysis (OOA), design (OOD) and programming (OOP) are related but distinct. OOA feedback WEEK 9: SOFTWARE TESTING Program testing Testing is intended □ to show that a program does what it is intended to do and □ to
is concerned with developing an object model of the application domain. OOD is concerned with developing an object-oriented system model to discover program defects before it is put into use. When you test software, you execute a program using artificial data. You check the results of the
implement requirements. OOP is concerned with realising an OOD using an OO programming language such as Java or C++. Objects and object test run for errors, anomalies or information about the program's nonfunctional attributes. Can reveal the presence of errors NOT their absence.
classes • An object is an entity that has a state and a defined set of operations which operate on that state. • The state is represented as a set of Testing is part of a more general verification and validation process, which also includes static validation Program testing goals Validation testing To
object attributes. • The operations associated with the object provide services to other objects (clients) which request these services when some demonstrate to the developer and the customer that the software meets its requirements. Defect testing To discover situations in which the
computation is required. • Objects are created according to some object class definition. • An object class definition serves as a template for behavior of the software is incorrect, undesirable or does not conform to its specification Verification vs validation ►Verification: "Are we building
objects. It includes declarations of all the attributes and services which should be associated with an object of that class. An OOD process the product right”. □ The software should conform to its specification. ►Validation: "Are we building the right product”. □ The software should do
Structured OOD processes involve designing object classes and relationship between these classes. Object-oriented systems are easier to change what the user really requires. 7 ơ ơ a V & V confidence Aim of V & V is to establish confidence that the system is 'fit for purpose'. Depends on □
than systems developed using functional approaches. □ Objects include both data and operations to manipulate that data. □ They may therefore Software purpose: The level of confidence depends on how critical the software is to an organisation. □ User expectations: Users may have low
be understood and modified as stand-alone entities. Changing the implementation of an object or adding services should not affect other system expectations of certain kinds of software. □ Marketing environment: Getting a product to market early may be more important than finding defects
objects. Process stages To develop an OOD from concept to detailed, there are several things that you need to do: Define the context and modes in the program. Inspections and testing ►Software inspections □ Concerned with analysis of the static system representation to discover
of use of the system Design the system architecture Identify the principal system objects Develop design models later in detail Specify object problems(static verification) □ May be supplement by tool-based document and code analysis. ►Software testing □ Concerned with exercising and
interfaces 1. Define the context and modes of use of the system System context and interactions Understanding the relationships between the observing product behaviour (dynamic verification) □ The system is executed with test data and its operational behaviour is observed ► Both are
software that is being designed and its external environment is essential for deciding □ how to provide the required system functionality and □ how complementary and not opposing verification techniques. Both should be used during the V & V process. Inspections can check conformance with
to structure the system to communicate with its environment. Understanding of the context also lets you establish the boundaries of the system. a specification but not conformance with the customer's real requirements. Inspections cannot check non-functional characteristics such as
Setting the system boundaries helps you decide □ what features are implemented in the system being designed and □ what features are in other performance, usability, etc. Software inspections Involve people examining the source representation with the aim of discovering anomalies and
associated systems. Context and interaction models ►System context □ A static model that describes other systems in the environment. □ Use a defects. Do not require execution of a system so may be used before implementation. May be applied to any representation of the system
subsystem model to show other systems. ►Model of system use □ A dynamic model that describes how the system interacts with its environment. (requirements, design, configuration data, test data, etc.). Have been shown to be an effective technique for discovering program errors.
□ Use use-cases to show interactions 2. Design the system architecture Architectural design Once interactions between the system and its Advantages of inspections □ During testing, errors can mask (hide) other errors. Because inspection is a static process, you don't have to be
environment have been understood, you use this information for designing the system architecture. □ identify the major components that make up concerned with interactions between errors. □ Incomplete versions of a system can be inspected without additional costs. □ As well as searching
the system and their interactions, and □ then organize the components using an architectural pattern such as a layered or clientserver model. for program defects, an inspection can also consider broader quality attributes of a program □ such as compliance with standards, portability and
Process stages To develop an OOD from concept to detailed, there are several things that you need to do: • Define the context and modes of use maintainability. Stages of testing Development testing □ the system is tested during development to discover bugs and defects. Release testing □ a
of the system • Design the system architecture • Identify the principal system objects • Develop design models Specify object interfaces 3. Identify separate testing team tests a complete version of the system before it is released to users. User testing □ users or potential users of a system test
the principal system objects Object class identification Identifying object classes is often a difficult part of object oriented design. There is no 'magic the system in their own environment. 1. Development testing Includes all testing activities that are carried out by the team developing the system.
formula' for object identification. □ It relies on the skill, experience and domain knowledge of system designers. Object identification is an iterative Unit testing □ Individual program units or object classes are tested. □ Should focus on testing the functionality of objects or methods. Component
process. You are unlikely to get it right first time.. 4. Develop design models Design models Design models show □ the objects or object classes in testing □ Several individual units are integrated to create composite components. □ Should focus on testing component interfaces. System testing
a system and □ the relationships between these entities. Static models describe the static structure of the system in terms of object classes and □ Some or all of the components in a system are integrated and the system is tested as a whole. Unit testing Is the process of testing individual
relationships. Dynamic models describe the dynamic interactions between objects. Subsystem models Are static models. Shows how the design is components in isolation. Is a defect testing process. Units may be: □ Individual functions or methods within an object □ Object classes with several
organised into logically related groups of objects. In the UML, these are shown using packages - an encapsulation construct. □ □ This is a logical attributes and methods □ Composite components with defined interfaces used to access their functionality. 18 Object class testing Complete test
model. The actual organisation of objects in the system may be different. Sequence models Are dynamic models. Sequence models show the coverage of a class involves □ Testing all operations associated with an object □ Setting and interrogating all object attributes □ Exercising the
sequence of object interactions that take place □ □ Objects are arranged horizontally across the top; Time is represented vertically so models are object in all possible states. Inheritance makes it more difficult to design object class tests as the information to be tested is not localised. 19
read top to bottom; □ Interactions □ are represented by labelled arrows, Different styles of arrow represent different types of interaction; A thin Automated testing Whenever possible, unit testing should be automated so that tests are run and checked without manual intervention. In
rectangle in an object lifeline represents the time when the object is the controlling object in the system . State diagrams Are dynamic models. Are automated unit testing: use a test automation framework (such as JUnit) to write and run program tests. □ Unit testing frameworks provide generic
used to show □ how objects respond to different service requests and □ the state transitions triggered by these requests. Are useful high-level 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
models of a system or an object's run-time behavior. You don't usually need a state diagram for all of the objects in the system. □ Many of the some GUI, he success of otherwise of the tests. 23 Automated test components A setup part □ initialize the system with the test case, namely the
objects in a system are relatively simple and a state model adds unnecessary detail to the design. 4. Specify object interfaces Interface inputs and expected outputs. □ A call part □ call the object or method to be tested. An assertion part □ compare the result of the call with the
specification Object interfaces have to be specified so that the objects and other components can be designed in parallel. Designers should avoid expected result. If the assertion evaluates to true, the test has been successful; if false, then it has failed. Unit test effectiveness If there are defects
designing the interface representation but should hide this in the object itself. Objects may have several interfaces which are viewpoints on the in revealed by test cases The test cases should show that the component that you are testing does what it is supposed to do. the component,
methods provided. The UML uses class diagrams for interface specification but Java may also be used. 2. Design patterns A pattern is a these should be 2 types of unit test case: □ The first type: reflect normal operation of a program and should show that the component works as
description of the problem and the essence of its solution. It should be sufficiently abstract to be reused in different settings. Pattern descriptions expected. □ The second type: based on testing experience of where common problems arise. It should use abnormal inputs to check that these
usually make use of object-oriented characteristics such as inheritance and polymorphism. Design problems To use patterns in your design, you are properly processed and do not crash the component. Testing strategies Partition testing □ Identify groups of inputs that have common
need to recognize that any design problem you are facing may have an associated pattern that can be applied. □ Tell several objects that the state characteristics and should be processed in the same way. □ Should choose tests from within each of these groups. Guideline-based testing □ Use
of some other object has changed (Observer pattern). □ Tidy up the interfaces to a number of related objects that have often been developed testing guidelines to choose test cases. □ These guidelines reflect previous experience of the kinds of errors that programmers often make when
incrementally (Fagade pattern). □ Provide a standard way of accessing the elements in a collection, irrespective of how that collection is developing components. Partition testing Input data and output results often fall into different classes where all members of a class are related.
implemented (Iterator pattern). □ Allow for the possibility of extending the functionality of an existing class at run-time (Decorator pattern). 3. Each of these classes is an equivalence partition or domain where the program behaves in an equivalent way for each class member. Test cases
Implementation issues Focus here is not on programming, although this is obviously important, but on other implementation issues that are often should be chosen from each partition. Example: Testing guidelines (sequences) □ Test software with sequences which have only a single value.
not covered in programming texts: □ □ □ Reuse Most modern software is constructed by reusing existing components or systems. When you are 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
developing software, you should make as much use as possible of existing code. Configuration management During the development process, you sequences of zero length. General testing guidelines Choose inputs that force the system to generate all error messages Design inputs that cause
have to keep track of the many different versions of each software component in a configuration management system. Host-target development input buffers to overflow Repeat the same input or series of inputs numerous times Force invalid outputs to be generated Force computation
Production software does not usually execute on the same computer as the software development environment. Rather, you develop it on one results to be too large or too small. Component testing Software components are often composite components that are made up of several
computer (the host system) and execute it on a separate computer (the target system). Reuse From the 1960s to the 1990s, most new software interacting objects. You access the functionality of these objects through the defined component interface. Testing composite components should
was developed from scratch, by writing all code in a high-level programming language. □ The only significant reuse or software was the reuse of therefore focus on showing that the component interface behaves according to its specification. □ You can assume that unit tests on the individual
functions and objects in programming language libraries. Costs and schedule pressure mean that this approach became increasingly unviable, objects within the component have been completed. Interface testing Objectives: detect faults due to interface errors or invalid assumptions about
especially for commercial and Internet-based systems. An approach to development based around the reuse of existing software emerged and is interfaces. □ Interface types □ Parameter interfaces Data passed from one method or procedure to another. □ Shared memory interfaces Block of
now generally used for business and scientific software. Reuse levels The abstraction level □ At this level, you don't reuse software directly but use memory is shared between procedures or functions. □ Procedural interfaces Sub-system encapsulates a set of procedures to be called by other
knowledge of successful abstractions in the design of your software. The object level □ At this level, you directly reuse objects from a library rather sub-systems. □ Message passing interfaces Sub-systems request services from other sub-systems 34 Interface errors □ Interface misuse □ A
than writing the code yourself. The component level □ Components are collections of objects and object classes that you reuse in application calling component calls another component and makes an error in its use of its interface e.g. parameters in the wrong order. □ Interface
systems. The system level □ At this level, you reuse entire application systems Reuse costs The costs of the time spent in looking for software to misunderstanding □ A calling component embeds assumptions about the behaviour of the called component which are incorrect. □ Timing errors □
reuse and assessing whether or not it meets your needs. Where applicable, the costs of buying the reusable software. For large off-the-shelf The called and the calling component operate at different speeds and out-of-date information is accessed. 35 Interface testing guidelines Design
systems, these costs can be very high. The costs of adapting and configuring the reusable software components or systems to reflect the tests so that parameters to a called procedure are at the extreme ends of their ranges. Always test pointer parameters with null pointers. Design
requirements of the system that you are developing. The costs of integrating reusable software elements with each other (if you are using software tests which cause the component to fail. Use stress testing in message passing systems. In shared memory systems, vary the order in which
from different sources) and with the new code that you have developed. Open source development is an approach to software development □ the components are activated. System testing Involves integrating components to create a version of the system and then testing the integrated
source code of a software system is published and volunteers are invited to participate in the development process. Free Software Foundation system. Focus on testing the interactions between components. Checks that components are compatible, interact correctly and transfer the right
(www.fsf.org) □ "The Free Software Foundation (FSF) is a nonprofit with a worldwide mission to promote computer user freedom. We defend the data at the right time across their interfaces. System and component testing During system testing, reusable components that have been
rights of all software users." Open source software extended this idea by using the Internet to recruit a much larger population of volunteer separately developed and off-the-shelf systems may be integrated with newly developed components. The complete system is then tested.
developers. Many of them are also users of the code. 65 Open source systems The best-known open source product is the Linux operating system Components developed by different team members or sub-teams may be integrated at this stage. System testing is a collective rather than an
□ is widely used as a server system and, increasingly, as a desktop environment. Other important open source products are Java, the Apache web individual process. □ In some companies, system testing may involve a separate testing team with no involvement from designers and
server and the mySQL database management system. Open source issues For a company: □ Should the product that is being developed make programmers. 38 Use-case testing The use-cases developed to identify system interactions can be used as a basis for system testing. Each use
use of open source components? □ Should an open source approach be used for the software’s development? 67 Open source business More case usually involves several system components so testing the use case forces these interactions to occur. The sequence diagrams associated
and more product companies are using an open source approach to development. Their business model is not reliant on selling a software product with the use case documents the components and interactions that are being tested. Testing policies Exhaustive system testing is impossible so
but on selling support for that product. They believe that involving the open source community will allow software to be developed more cheaply, testing policies which define the required system test coverage may be developed. Examples of testing policies: □ All system functions that are
more quickly and will create a community of users for the software. Open source licensing A fundamental principle: source code should be freely accessed through menus should be tested. □ Combinations of functions that are accessed through the same menu must be tested. □ Where user
available, this does not mean that anyone can do as they wish with that code. Legally, the developer of the code still owns the code. □ □ □ They input is provided, all functions must be tested with both correct and incorrect input. 2. Test-driven development □ An approach to program
can place restrictions on how it is used by including legally binding conditions in an open source software license. Some open source developers development in which you inter-leave testing and code development. Tests are written before code and 'passing' the tests is the critical driver of
believe that if an open source component is used to develop a new system, then that system should also be open source. Others are willing to development. You develop code incrementally, along with a test for that increment. Part of agile methods, such as Extreme Programming. □ It can
allow their code to be used without this restriction. The developed systems may be proprietary and sold as closed source systems. WEEK 8: UI also be used in plan-driven development processes. TDD process activities □ Start by identifying the increment of functionality that is required. □
DESIGN 1. Design issues User interfaces should be designed to match the skills, experience and expectations of its anticipated users. System This should normally be small and implementable in a few lines of code. □ Write a test for this functionality and implement this as an automated
users often judge a system by its interface rather than its functionality. A poorly designed interface □ Can cause a user to make catastrophic errors. test. Run the test, along with all other tests that have been implemented. □ Initially, you have not implemented the functionality so the new test will
□ Is the reason why so many software systems are never used. 7 Human factors in interface design Limited short-term memory □ People can fail. Implement the functionality and re-run the test. Once all tests run successfully, you move on to implementing the next chunk of functionality.
instantaneously remember about 7 items of information. If you present more than this, they are more liable to make mistakes. People make Benefits of test-driven development Code coverage □ Every code segment that you write has at least one associated test è all code written has at
mistakes □ When people make mistakes and systems go wrong, inappropriate alarms and messages can increase stress and hence the likelihood least one test. Regression testing □ A regression test suite is developed incrementally as a program is developed. Simplified debugging □ When a
of more mistakes. People are different □ People have a wide range of physical capabilities. Designers should not just design for their own test fails, it should be obvious where the problem lies. The newly written code needs to be checked and modified. System documentation □ The
capabilities. People have different interaction preferences □ Some like pictures, some like text. 8 UI design principles UI design must take account tests themselves are a form of documentation that describe what the code should be doing. 46 Regression testing Regression testing is testing the
of the needs, experience and capabilities of the system users. Designers should □ be aware of peoples physical and mental limitations (e.g. limited system to check that changes have not 'broken' previously working code. In a manual testing process, regression testing is expensive but, with
short-term memory) and □ should recognise that people make mistakes. □ UI design principles underlie interface designs although not all automated testing, it is simple and straightforward. All tests are rerun every time a change is made to the program. Tests must run 'successfully'
principles are applicable to all designs. 9 UI design principles User familiarity □ The interface should use terms and concepts which are drawn from before the change is committed. 3. RELEASE TESTING □ Is the process of testing a particular release of a system that is intended for use outside
the experience of the people who will make most use of the system. Consistency □ The interface should be consistent in that, wherever possible, of the development team. Main goal: convince the supplier of the system that it is good enough for use. Is usually a black-box testing process
comparable operations should be activated in the same way. Minimal surprise □ Users should never be surprised by the behaviour of a system. 10 where tests are only derived from the system specification. Release testing and system testing Release testing is a form of system testing.
UI design principles Recoverability □ The interface should include mechanisms to allow users to recover from errors. User guidance □ The Important differences: □ A separate team that has not been involved in the system development, should be responsible for release testing. □
interface should provide meaningful feedback when errors occur and provide context-sensitive user help facilities. User diversity □ The interface System testing by the development team should focus on discovering bugs in the system (defect testing). The objective of release testing is to
should provide appropriate interaction facilities for different types of system user. Design issues in UIs □ Two problems must be addressed in check that the system meets its requirements and is good enough for external use (validation testing). 50 Requirements-based testing
interactive systems design □ How should the user interact with the computer system? □ How should information from the computer system be Requirements-based testing involves examining each requirement and developing a test or tests for it. □ Mentcare system requirements: □ If a
presented to the user? Interaction styles Direct manipulation Menu selection Form fill-in Command language Natural language 13 Interaction styles patient is known to be allergic to any particular medication, then prescription of that medication shall result in a warning message being issued to
Main advantages style Direct Fast and intuitive manipulation interaction Easy to learn Menu Avoids user error selection Little typing required Form the system user. □ If a prescriber chooses to ignore an allergy warning, they shall provide a reason why this has been ignored. Performance