Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Software Engineering for the Internet

Slides for the lecutre "Software Engineering for the Internet", based heavily on the book "Software Engineering" by Ian Sommerville. This presentation is still work in progress!
by

Pedro Gonnet

on 15 January 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Software Engineering for the Internet

"We don't have time to gather requirements. If we don't start coding right now, we'll never meet our deadline.“ Requirements engineering Requirements are the description of what services a system should provide, and the constraints on its operation. The process of discovering, analyzing and describing these requirements is called "Requirements engineering". Requirements exist at different levels for different types of readers. Why are requirements needed? Not just technical, communication skills are important too. Requirement types Requirements engineering process Most important source of failure “There is little doubt that project requirements are the single biggest cause of trouble on the software project front. Study after study has found that, where there is failure, requirements problems are usually at the heart of the matter”

Glass, 1998 (Software Runaways) Connecting for Health: currently behind schedule and over budget, doctors not properly consulted over it. Swanick Air Traffic Control: completed four years late, massively over budget, investigation concluded “proceeding with system implementation without a robust requirements specification” (HMSO 1999). London Ambulance Service despatch system: closed in 1992 after 2 days of operation, “poor requirements analysis within social domain”. Long list of examples A 2003 study of the sources of error in US Air Force projects revealed that 41% of failures are due to incorrect requirement specifications. The need for good requirements Requirements should clearly state what it is that a given software project is supposed to build and deliver. Substituting this definition into the above statement gives some insight as to what can go wrong. "We don't have time to figure out what we need to build and deliver. If we don't start coding right now, we'll never meet our deadline.“ What are requirements used for? Project scoping
Cost estimating
Budgeting
Project scheduling
Software design
Software testing
Documentation and training manuals Requirements are not just for customers, but are useful for everybody involved in a software project! In summary Good requirement engineering is crucial for a software project's success. You need to specify what you are going to do before you start thinking about how you are going to do it. Requirements engineering is a process that involves all stakeholders in a software project, from the customers down to the developers. User/System requirements Requirements are usually separated into user and system requirements. User requirements are statements, in a natural language plus diagrams, of what services the system is expected to provide to system users and the constraints under which it must operate. System requirements are more detailed descriptions of the software system's functions, services and operational constraints, defining exactly what is to be implemented. The distinction between user and system requirements is not always clear-cut and may vary depending on the level of the intended audience, e.g. customer or end-user. Example 1. The MHC-PMS shall generate monthly management reports sowing the cost of drugs prescribed by each clinic during that month. 1.1 On the last working day of each month, a summary of the drugs prescribed, their cost, and the prescribing clinics shall be generated. 1.2 The system shall automatically generate the report for printing after 17.30 on the last working day of the month. 1.3 A report shall be created for each clinic and shall list the individual drug names, the total number of prescriptions, the number of doses prescribed, and the total cost of the prescribed drugs. 1.4 If drugs are available in different dose units (e.g., 10mg, 20mg) separate reports shall be created for each dose unit. 1.5 Access to all cost reports shall be restricted to authorized users listed on a management access control list. User requirement System requirements Functional requirements Requirements can also be separated into functional and non-functional requirements. Functional requirements Non-Functional requirements Whereas the former describes the specific behaviour of a system, the latter describes the constraints on this behaviour in more qualitative terms. Completeness and consistency The functional requirements specification should be both complete and consistent. Summary Functional requirements describe the functionality and behaviour of system services. Definition Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. Examples Functional requirements for a patient management system (Sommerville, 2011) Specificity Your job, as a Software Engineer, is to implement requirements, not to interpret them. It is therefore of utmost importance that the requirements be as specific as possible. Functional requirements describe the functionality of system services. They vary in the level of detail used to describe what is done, from very general user requirements to very specific system requirements. Functional requirements describe required behaviour in terms of required activities such as reactions to inputs and the state of each entity before and after activity occurs. A user shall be able to search the appointments lists for all clinics. Each staff member using the system shall be uniquely identified by his or her eight-digit employee number. The system shall generate each day, for each clinic, a list of patients who are expected to attend appointments that day. Each requirement defines a specific facility provided by the system. These requirements vary significantly in the level of detail with which they are specified. Imprecision in the requirements specification is the cause of many software engineering problems (Sommerville, 2011). In the previous example, the first requirement does not state how this search is performed, e.g. What search criteria may be used, e.g. patient name, patient ID, appointment time, appointment type, etc... On a per-patient basis or per-clinic basis, Completeness implies that all services required by the user should be defined, i.e. there is no need for interpretation on the developer side. Consistency implies that the functional do not have contradictory definitions. In practice, for large, complex systems, it is practically impossible to achieve requirements consistency and completeness, e.g. due to the system size, or too many stakeholders with different needs Problems with completeness and consistency usually only emerge later on in the design or development of the system, requiring an iterative approach to software development/improvement. Functional requirements exist at different levels of detail for different reader/user types. Functional requirements should be complete and consistent, although this is difficult for larger projects. Functional requirements should be as specific as possible to avoid leaving requirements to the developers. Goals vs. requirements Users or customers often formulate non-functional requirements as general goals, e.g. Metrics Non-functional requirements should be specified quantitatively, such that they can be objectively tested. Definition Non-functional requirements are constraints not directly associated with specific services provided by the system, e.g. reliability, response time, security, size, etc... Classification Non-functional requirements are generally classified in three classes: Examples Often more critical than individual functional requirements, as failing to meet them can mean that the whole system is unusable. Generally difficult to relate individual system components to non-functional requirements, as their implementation may permeate the entire system. A single non-functional requirement, e.g. security, may generate a number of related, or restrict existing, functional requirements. Arise through user needs, budget constraints, policies, or external factors such as regulation. Product
requirements Organizational requirements External
requirements Usability requirements, These requirements specify or constrain the behaviour of the software, e.g. Security requirements. Dependability requirements, Efficiency requirements, e.g. space and/or speed, Environmental requirements, Requirements derived from the policies and procedures of the customer's and developer's organization, e.g. Development requirements. Operational requirements, Regulatory requirements, All requirements derived from factors external to the system and the development process, e.g. Ethical requirements. Legislative requirements, e.g. accounting, safety, and security, Non-functional requirements for a patient management system: Product requirement: The system shall be available to all clinics during normal working hours (Mon-Fri, 0830-17.30). Downtime within normal working hours shall not exceed five seconds in any one day. Organizational requirement: Users of the system shall authenticate themselves using their health authority identity card. External requirement: The system shall implement patient privacy provisions as set out in HStan-03-2006-priv. These requirements are very precise, but say nothing about the functionality of the system. The system should be easy to use my medical staff and should be organized in such a way that user errors are minimized. Although non-functional requirements do not relate to specific services of the system, they still need to be specific to avoid interpretation, e.g. Medical staff shall be able to use all the system functions after four hours of training. After this training, the average number of errors made by users shall not exceed two per hour of use. Summary Non-Functional requirements describe the constraints under which a system is supposed to operate. Some common metrics used to specify such requirements are: Speed: Processed transactions/second, response time. Robustness: Probability of data corruption after failure. Reliability: Probability/rate of failure, availability. Ease of use: Training time, number of help frames. For some requirements, e.g. maintainability, metrics can be difficult to define. Non-Functional requirements can result from product, organizational or external needs. Non-Functional requirements should be written as measurable requirements and not abstract goals. Non-Functional requirements should be written using metrics against which they can be tested. Feasibility study Requirements discovery and analysis Requirements specification Requirements validation System models User and system requirements Requirements document Low cost way of avoiding problems. Phases of feasibility study: Sources of information can be used in discovery phase. Provide adequate returns for the investment? Business objectives need to be made explicit. Reveals if a system is actually needed and/or technologically realistic. Produce a feasibility report describing advantages and disadvantages of the system, and make recommendations Gather that information from key information sources Decide on information that is actually needed. Req. discovery Req. prioritization and negotiation Req. specification Req. classification and organization Work with stakeholders to find out about the application domain, what services are required, under which constraints, etc... Stakeholders are people who interact with the system, or will be affected by it, e.g. end-users, managers, administrators, regulators, etc... Main issues Interviews Scenarios Use cases Ethnography Summary Stakeholders often only know, or may not be able to articulate, what they want from a computer system in the most general terms. Stakeholders often do not know what is feasible, or what is not. Stakeholders will often express requirements in their own terms and with implicit knowledge of their own domain/work. Different stakeholders will interact with the system in different ways and will therefore also view its services in different ways. Political, i.e. non-rational, factors may influence the requirements, e.g. managers may demand requirements to influence their position within the organization. The stakeholders may operate in a dynamic environment where both the requirements and the actual stakeholders change often. Interviews with system stakeholders are part of most requirement engineering processes. In closed interviews, the stakeholder answers a set of pre-determined questions, as opposed to open interviews, for which there is no agenda. Although interviews are good for dicovering requirements of the system, they are not so helpful in understanding the domain. Interviews are a fundamentally human activity and as such, there is no precise methodology, but: Its a good idea to start by just listening. It is your job to ask the right questions. Scenarios are descriptions of example interaction sessions with the proposed system. Particularly useful for adding detail to a general requirements description. Scenarios can be extended iteratively, adding details to create a complete description of that interaction. A good description of a scenario should include: A description of what is expected when the scenario starts; Of the normal flow of events; Of what can go wrong and how this is handles; Of other concurrent activities; Of the system state after the interaction. Scenarios can be recorded as text, and/or diagrams, screen shots, etc... Use cases identify the actors involved in an interaction and names the type of interaction. Usually documented using a high-level use case diagram, describing all possible interactions of the system, and a brief textual description. All actors, e.g. humans or systems, are represented as stick figures. Each type of interaction is represented in a named ellipse. Similar to scenarios, yet each use case can contain several scenarios or vice versa. Ethnography attempts to describe how the social and organizational context of the end users affects the practical operation of the system. Ethnographers immerse themselves in the working environment where the system will be used and observes the actual tasks in which the participants are involved. The goal is to extract social and organizational factors which are not obvious to the individuals involved themselves. Particularly effective for discovering requirements derived from non-standard situations, and cooperative activities. Requirements discovery is an inherently human process. Several different methods exist, each with its own strengths for describing different types of requirements. In practice, several or all such methods are used together. In the end, you should have: A description of the problem domain,
The basic type of application,
The identity of the stakeholders,
The main motivation behind the development,
List of problems requiring solutions (the requirements),
Any stakeholder imposed constraints. Group related requirements and organize them into coherent clusters. Use a model of the system architecture to identify sub-systems and associate requirements to each sub-system. Tightly related to architectural design, i.e. the two are not completely separate activities. In most cases, when multiple stakeholders are involved, the initial requirements will conflict. Conflicting requirements must be identified and prioritized. Conflicts must be resolved through negotiation with the respective stakeholders, which must agree on compromise requirements. Main issues Context models Process models Interaction models Behavioural models Structural models System modeling is the process of developing abstract models of a system. Different models present different views or perspectives of a system, e.g. focusing on different aspects thereof.. Generally, system modeling has come to mean representing the system using some kind of graphical notation, usually based on UML. System models are used at all levels of the software engineering process, e.g. to describe requirements, system design, and/or system documentation. System models are an abstraction of the system, e.g. a reduced representation in which not all details are shown. Context models are used to define the system boundaries, e.g. what the system should do and what not, as well as how it interfaces with the outside world. Process models describe human and automated processes in which the system is used, using UML activity diagrams. Sequence diagrams in UML are used primarily to model the interactions between the actors and the objects in the system, as well as between the objects themselves. Behavioural models describe what is supposed to happen when a system responds to a stimulus, e.g. data or an event, from the environment. Structural models display the organization of a system in terms of the components that make up that system, and their relationships. Context models usually produce a simple architectural model of the system. Since only the context is being modeled, the types of interactions between the systems are not specified. They show the individual activities that make up a process, as well as the flow of control from one activity to another. The start and end states are indicated by solid and outlined circles respectively. Rounded rectangles indicate activities that need to be carried out. Solid bars represent activity coordination. Objects and actors are listed along the top of the diagram and the rectangles below them indicates their lifeline. Arrows indicate interactions between actors and/or objects. Annotations on the arrows indicate function calls, parameters, and return values. UML state diagrams can be used for systems with a finite number of states. They do not show the flow of data, but may containt information on the operations or computations carried out at each step. UML class diagrams can be used to describe the classes in a system, their fields and methods, as well as their relation to each other. These diagrams can represent the classes and their relations at different levels of detail. Summary System modeling is the process of developing simplified models of a system. Different models present different views or perspectives of a system, e.g. focusing on different aspects thereof. Graphical models add more information to textual specifications. System modelling is a good way to present overall picture of “normal” operations but can become cluttered when exception information added Although most graphical notations follow the UML, similar symbols may be interpreted differently. Some UML editing tools allow for the automatic generation of code from graphical models. Formulate the user and system requirements in such a way that they are clear, unambiguous, easy to understand, complete, and consistent. User requirements should specify only the external behaviour of the system, and be understandable by stakeholders at all levels, i.e. also for readers without detailed technical knowledge. System requirements should are often the starting point for the system design and should therefore be a complete and detailed specification of the whole system. User requirements are usually written in natural language and supplemented by diagrams and tables. System requirements are usually supplemented by other, graphical or formal, notations, e.g. UML diagrams or pseudocode. Main issues Requirement validation is the process of checking whether the requirements actually match what the customer really wants. Checking requirements Once specified, requirement need to be checked with respect to a number of criteria, which should include: Validity checks: Does the system provide the functionality that best supports the customer's needs? Consistency checks: Do we have conflicting requirements, e.g. for the same functionality, but seen from different stakeholders? Completeness checks: Are all functions and constraints specified, e.g. are there no open questions about what the system should do? Realism checks: Can the requirements actually be implemented at all, or within the given budget and schedule constraints? Verifyability checks: Are all the requirements empirically verifiable? Requirements reviews Requirement reviews are systematic and manual analysis of the requirements. Prototyping In this approach, an executable model of the system is demonstrated to end-users and other stakeholders. Test-case generation In order to be testable, each requirement should come with a "fit" criteria against which a solution can be evaluated. Summary Requirements validation is a crucial part of the requirements engineering process. This is an important process since the costs of changing requirements once the system has been implemented can be huge, e.g. if the fixed requirements lead to extensive changes in the system design and implementation. The sooner requirement problems are caught, the easier and cheaper they are to fix. All stakeholders should be involved in the process, both on the customer and developer side. Problems with the consistency and completeness can usually only be found this way, e.g. by scrutinizing the requirements as a whole. Formal requirement reviews consist of walking the customer through the system requirements. Two main approaches to prototyping Evolutionary: Iteratively refined prototypes that will eventually be used in the implementation. Throwaway: "Quick and dirty" prototypes that are used only in the requirements engineering process, So-called rapid prototyping is a mix of both approaches, e.g. a partial solution built to help understand the problem. Usually either implement all features of a single function, or all functions with limited features. Not all fit criteria can be tested before the product is delivered, e.g. for non-functional requirements with regards to reliability. The fit criteria should also be reasonably testable, e.g. for a nuclear power plant, "In the case of a reactor melt-down, the system shall reduce the deaths of personnel within a 20 mile radius by at least 80%" Agreed-upon testing criteria become crucial if there are any disagreements with the customer once a system has been delivered. Several different types of checks are required. Review, prototypes and test-case generation are important tools in validating requirements. For large, complex systems, getting all the requirements right is almost impossible, which is why both the requirements and software engineering processes are usually iterative. Purpose The requirements documents is a full description of what the system should do, but not of how it should do it. Users Different stakeholders will use the requirements document in different ways: System customers: Specify the requirements and read them to check that they meet their needs. Customers specify changes to the requirements. Managers: Use the requirements document to plan a bid for the system and to plan the system development process. System engineers: Use the requirements to understand what system is to be developed. System test engineers: Use the requirements to develop validation tests for the system System maintenance engineers: Use the requirements to understand the system and the relationship between its parts. Level of detail Level of detail required depends on a number of factors: IEEE standard structure The IEEE standard 830-1998 provides guidance on the structure of system requirements documents. IEEE standard features The IEEE standard also specifies some general characteristics of the requirements document: Recommendations Develop your own structured notation to describe requirements, e.g. name, description, inputs, outputs, actions, diagrams, etc... And stick to it throughout the entire document. It gives full visibility and secure record of the required behaviour. Facilitates the future development of new systems with similar functionality. Provides information for production of user manuals and other forms of training documentation. It provides a baseline against which functionality can be tested. Ensures correct information is accurately communicated to the developers and facilitates future maintenance. The type of system being developed, i.e. how likely and often it is to be updated and/or extended. The development process used, e.g. in agile processes requirements are added incrementally. The level of external scrutiny, e.g. for safety-critical systems. The type of relationship between the customer and software engineers, e.g. if the system is being developed in-house or by an outside contractor. The diversity of possible users means that the requirements document has to be a compromise between communicating the requirements to customers and defining the requirements in detail for developers and testers. Introduction: Overview of the purpose and scope of the entire system, provide the definitions of all terms, acronyms, and abbreviations used. General description: This section does not state specific requirements, but instead provides a background and context for those requirements, e.g. context models, what functions the system will perform, and the outside constraints on the system. Specific requirements: User and system requirements, both functional and non-functional, e.g. interfaces, functions, and specific constraints. The IEEE standard is very general, but provides a good framework from which to extract a useful structure for a specific case. Correct: Every requirement is actually required by the system. Unambiguous: Every requirement has only one interpretation. Complete: All the significant requirements, whether relating to functionality, performance, design constraints, attributes or external interfaces are included. Consistent: The requirements are all mutually consistent. Ranked: Requirements are given an unambiguous order of priority. Verifiable: All requirements are verifiable and can be tested. Modifiable: Any changes to the requirements can be made easily, completely, and consistently Traceable: The origin of each requirement is clearly specified. Avoid the use of jargon, i.e. you should not need any as the requirements document is a description of what is to be done, and not how. Develop a numbering scheme for your requirements, and use it consistently throughout the document to improve traceability. Be as consistent as possible in style, format, nomenclature, etc... This may be challenging when working as a group, but has a significant effect on the readability of the document. "We don't have time to gather requirements. If we don't start coding right now, we'll never meet our deadline.“ The process of discovering, analyzing and describing these requirements is called "Requirements engineering". Requirements exist at different levels for different types of readers. Why are requirements needed? Not just technical, communication skills are important too. Requirement types Requirements engineering process Most important source of failure “There is little doubt that project requirements are the single biggest cause of trouble on the software project front. Study after study has found that, where there is failure, requirements problems are usually at the heart of the matter”

Glass, 1998 (Software Runaways) Connecting for Health: currently behind schedule and over budget, doctors not properly consulted over it. Swanick Air Traffic Control: completed four years late, massively over budget, investigation concluded “proceeding with system implementation without a robust requirements specification” (HMSO 1999). London Ambulance Service despatch system: closed in 1992 after 2 days of operation, “poor requirements analysis within social domain”. Long list of examples A 2003 study of the sources of error in US Air Force projects revealed that 41% of failures are due to incorrect requirement specifications. The need for good requirements Requirements should clearly state what it is that a given software project is supposed to build and deliver. Substituting this definition into the above statement gives some insight as to what can go wrong. "We don't have time to figure out what we need to build and deliver. If we don't start coding right now, we'll never meet our deadline.“ What are requirements used for? Project scoping
Cost estimating
Budgeting
Project scheduling
Software design
Software testing
Documentation and training manuals Requirements are not just for customers, but are useful for everybody involved in a software project! In summary Good requirement engineering is crucial for a software project's success. You need to specify what you are going to do before you start thinking about how you are going to do it. Requirements engineering is a process that involves all stakeholders in a software project, from the customers down to the developers. User/System requirements Requirements are usually separated into user and system requirements. User requirements are statements, in a natural language plus diagrams, of what services the system is expected to provide to system users and the constraints under which it must operate. System requirements are more detailed descriptions of the software system's functions, services and operational constraints, defining exactly what is to be implemented. The distinction between user and system requirements is not always clear-cut and may vary depending on the level of the intended audience, e.g. customer or end-user. Example 1. The MHC-PMS shall generate monthly management reports sowing the cost of drugs prescribed by each clinic during that month. 1.1 On the last working day of each month, a summary of the drugs prescribed, their cost, and the prescribing clinics shall be generated. 1.2 The system shall automatically generate the report for printing after 17.30 on the last working day of the month. 1.3 A report shall be created for each clinic and shall list the individual drug names, the total number of prescriptions, the number of doses prescribed, and the total cost of the prescribed drugs. 1.4 If drugs are available in different dose units (e.g., 10mg, 20mg) separate reports shall be created for each dose unit. 1.5 Access to all cost reports shall be restricted to authorized users listed on a management access control list. User requirement System requirements Functional requirements Requirements can also be separated into functional and non-functional requirements. Functional requirements Non-Functional requirements Whereas the former describes the specific behaviour of a system, the latter describes the constraints on this behaviour in more qualitative terms. Completeness and consistency The functional requirements specification should be both complete and consistent. Summary Functional requirements describe the functionality and behaviour of system services. Definition Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. Examples Functional requirements for a patient management system (Sommerville, 2011) Specificity Your job, as a Software Engineer, is to implement requirements, not to interpret them. It is therefore of utmost importance that the requirements be as specific as possible. Functional requirements describe the functionality of system services. They vary in the level of detail used to describe what is done, from very general user requirements to very specific system requirements. Functional requirements describe required behaviour in terms of required activities such as reactions to inputs and the state of each entity before and after activity occurs. A user shall be able to search the appointments lists for all clinics. Each staff member using the system shall be uniquely identified by his or her eight-digit employee number. The system shall generate each day, for each clinic, a list of patients who are expected to attend appointments that day. Each requirement defines a specific facility provided by the system. These requirements vary significantly in the level of detail with which they are specified. Imprecision in the requirements specification is the cause of many software engineering problems (Sommerville, 2011). In the previous example, the first requirement does not state how this search is performed, e.g. What search criteria may be used, e.g. patient name, patient ID, appointment time, appointment type, etc... On a per-patient basis or per-clinic basis, Completeness implies that all services required by the user should be defined, i.e. there is no need for interpretation on the developer side. Consistency implies that the functional do not have contradictory definitions. In practice, for large, complex systems, it is practically impossible to achieve requirements consistency and completeness, e.g. due to the system size, or too many stakeholders with different needs Problems with completeness and consistency usually only emerge later on in the design or development of the system, requiring an iterative approach to software development/improvement. Functional requirements exist at different levels of detail for different reader/user types. Functional requirements should be complete and consistent, although this is difficult for larger projects. Functional requirements should be as specific as possible to avoid leaving requirements to the developers. Goals vs. requirements Users or customers often formulate non-functional requirements as general goals, e.g. Metrics Non-functional requirements should be specified quantitatively, such that they can be objectively tested. Definition Non-functional requirements are constraints not directly associated with specific services provided by the system, e.g. reliability, response time, security, size, etc... Classification Non-functional requirements are generally classified in three classes: Examples Often more critical than individual functional requirements, as failing to meet them can mean that the whole system is unusable. Generally difficult to relate individual system components to non-functional requirements, as their implementation may permeate the entire system. A single non-functional requirement, e.g. security, may generate a number of related, or restrict existing, functional requirements. Arise through user needs, budget constraints, policies, or external factors such as regulation. Product
requirements Organizational requirements External
requirements Usability requirements, These requirements specify or constrain the behaviour of the software, e.g. Security requirements. Dependability requirements, Efficiency requirements, e.g. space and/or speed, Environmental requirements, Requirements derived from the policies and procedures of the customer's and developer's organization, e.g. Development requirements. Operational requirements, Regulatory requirements, All requirements derived from factors external to the system and the development process, e.g. Ethical requirements. Legislative requirements, e.g. accounting, safety, and security, Non-functional requirements for a patient management system: Product requirement: The system shall be available to all clinics during normal working hours (Mon-Fri, 0830-17.30). Downtime within normal working hours shall not exceed five seconds in any one day. Organizational requirement: Users of the system shall authenticate themselves using their health authority identity card. External requirement: The system shall implement patient privacy provisions as set out in HStan-03-2006-priv. These requirements are very precise, but say nothing about the functionality of the system. The system should be easy to use by medical staff and should be organized in such a way that user errors are minimized. Although non-functional requirements do not relate to specific services of the system, they still need to be specific to avoid interpretation, e.g. Medical staff shall be able to use all the system functions after four hours of training. After this training, the average number of errors made by users shall not exceed two per hour of use. Summary Non-Functional requirements describe the constraints under which a system is supposed to operate. Some common metrics used to specify such requirements are: Speed: Processed transactions/second, response time. Robustness: Probability of data corruption after failure. Reliability: Probability/rate of failure, availability. Ease of use: Training time, number of help frames. For some requirements, e.g. maintainability, metrics can be difficult to define. Non-Functional requirements can result from product, organizational or external needs. Non-Functional requirements should be written as measurable requirements and not abstract goals. Non-Functional requirements should be written using metrics against which they can be tested. Feasibility study Requirements discovery and analysis Requirements specification Requirements validation System models User and system requirements Requirements document Low cost way of avoiding problems. Phases of feasibility study: Sources of information can be used in discovery phase. Provide adequate returns for the investment? Business objectives need to be made explicit. Reveals if a system is actually needed and/or technologically realistic. Produce a feasibility report describing advantages and disadvantages of the system, and make recommendations Gather that information from key information sources Decide on information that is actually needed. Req. discovery Req. prioritization and negotiation Req. specification Req. classification and organization Work with stakeholders to find out about the application domain, what services are required, under which constraints, etc... Stakeholders are people who interact with the system, or will be affected by it, e.g. end-users, managers, administrators, regulators, etc... Main issues Interviews Scenarios Use cases Ethnography Summary Stakeholders often only know, or may not be able to articulate, what they want from a computer system in the most general terms. Stakeholders often do not know what is feasible, or what is not. Stakeholders will often express requirements in their own terms and with implicit knowledge of their own domain/work. Different stakeholders will interact with the system in different ways and will therefore also view its services in different ways. Political, i.e. non-rational, factors may influence the requirements, e.g. managers may demand requirements to influence their position within the organization. The stakeholders may operate in a dynamic environment where both the requirements and the actual stakeholders change often. Interviews with system stakeholders are part of most requirement engineering processes. In closed interviews, the stakeholder answers a set of pre-determined questions, as opposed to open interviews, for which there is no agenda. Although interviews are good for dicovering requirements of the system, they are not so helpful in understanding the domain. Interviews are a fundamentally human activity and as such, there is no precise methodology, but: Its a good idea to start by just listening. It is your job to ask the right questions. Scenarios are descriptions of example interaction sessions with the proposed system. Particularly useful for adding detail to a general requirements description. Scenarios can be extended iteratively, adding details to create a complete description of that interaction. A good description of a scenario should include: A description of what is expected when the scenario starts; Of the normal flow of events; Of what can go wrong and how this is handles; Of other concurrent activities; Of the system state after the interaction. Scenarios can be recorded as text, and/or diagrams, screen shots, etc... Use cases identify the actors involved in an interaction and names the type of interaction. Usually documented using a high-level use case diagram, describing all possible interactions of the system, and a brief textual description. All actors, e.g. humans or systems, are represented as stick figures. Each type of interaction is represented in a named ellipse. Similar to scenarios, yet each use case can contain several scenarios or vice versa. Ethnography attempts to describe how the social and organizational context of the end users affects the practical operation of the system. Ethnographers immerse themselves in the working environment where the system will be used and observes the actual tasks in which the participants are involved. The goal is to extract social and organizational factors which are not obvious to the individuals involved themselves. Particularly effective for discovering requirements derived from non-standard situations, and cooperative activities. Requirements discovery is an inherently human process. Several different methods exist, each with its own strengths for describing different types of requirements. In practice, several or all such methods are used together. In the end, you should have: A description of the problem domain,
The basic type of application,
The identity of the stakeholders,
The main motivation behind the development,
List of problems requiring solutions (the requirements),
Any stakeholder imposed constraints. Group related requirements and organize them into coherent clusters. Use a model of the system architecture to identify sub-systems and associate requirements to each sub-system. Tightly related to architectural design, i.e. the two are not completely separate activities. In most cases, when multiple stakeholders are involved, the initial requirements will conflict. Conflicting requirements must be identified and prioritized. Conflicts must be resolved through negotiation with the respective stakeholders, which must agree on compromise requirements. Main issues Context models Process models Interaction models Behavioural models Structural models System modeling is the process of developing abstract models of a system. Different models present different views or perspectives of a system, e.g. focusing on different aspects thereof.. Generally, system modeling has come to mean representing the system using some kind of graphical notation, usually based on UML. System models are used at all levels of the software engineering process, e.g. to describe requirements, system design, and/or system documentation. System models are an abstraction of the system, e.g. a reduced representation in which not all details are shown. Context models are used to define the system boundaries, e.g. what the system should do and what not, as well as how it interfaces with the outside world. Process models describe human and automated processes in which the system is used, using UML activity diagrams. Sequence diagrams in UML are used primarily to model the interactions between the actors and the objects in the system, as well as between the objects themselves. Behavioural models describe what is supposed to happen when a system responds to a stimulus, e.g. data or an event, from the environment. Structural models display the organization of a system in terms of the components that make up that system, and their relationships. Context models usually produce a simple architectural model of the system. Since only the context is being modeled, the types of interactions between the systems are not specified. They show the individual activities that make up a process, as well as the flow of control from one activity to another. The start and end states are indicated by solid and outlined circles respectively. Rounded rectangles indicate activities that need to be carried out. Solid bars represent activity coordination. Objects and actors are listed along the top of the diagram and the rectangles below them indicates their lifeline. Arrows indicate interactions between actors and/or objects. Annotations on the arrows indicate function calls, parameters, and return values. UML state diagrams can be used for systems with a finite number of states. They do not show the flow of data, but may containt information on the operations or computations carried out at each step. UML class diagrams can be used to describe the classes in a system, their fields and methods, as well as their relation to each other. These diagrams can represent the classes and their relations at different levels of detail. Summary System modeling is the process of developing simplified models of a system. Different models present different views or perspectives of a system, e.g. focusing on different aspects thereof. Graphical models add more information to textual specifications. System modelling is a good way to present overall picture of “normal” operations but can become cluttered when exception information added Although most graphical notations follow the UML, similar symbols may be interpreted differently. Some UML editing tools allow for the automatic generation of code from graphical models. Formulate the user and system requirements in such a way that they are clear, unambiguous, easy to understand, complete, and consistent. User requirements should specify only the external behaviour of the system, and be understandable by stakeholders at all levels, i.e. also for readers without detailed technical knowledge. System requirements should are often the starting point for the system design and should therefore be a complete and detailed specification of the whole system. User requirements are usually written in natural language and supplemented by diagrams and tables. System requirements are usually supplemented by other, graphical or formal, notations, e.g. UML diagrams or pseudocode. Main issues Requirement validation is the process of checking whether the requirements actually match what the customer really wants. Checking requirements Once specified, requirement need to be checked with respect to a number of criteria, which should include: Validity checks: Does the system provide the functionality that best supports the customer's needs? Consistency checks: Do we have conflicting requirements, e.g. for the same functionality, but seen from different stakeholders? Completeness checks: Are all functions and constraints specified, e.g. are there no open questions about what the system should do? Realism checks: Can the requirements actually be implemented at all, or within the given budget and schedule constraints? Verifyability checks: Are all the requirements empirically verifiable? Requirements reviews Requirement reviews are systematic and manual analysis of the requirements. Prototyping In this approach, an executable model of the system is demonstrated to end-users and other stakeholders. Test-case generation In order to be testable, each requirement should come with a "fit" criteria against which a solution can be evaluated. Summary Requirements validation is a crucial part of the requirements engineering process. This is an important process since the costs of changing requirements once the system has been implemented can be huge, e.g. if the fixed requirements lead to extensive changes in the system design and implementation. The sooner requirement problems are caught, the easier and cheaper they are to fix. All stakeholders should be involved in the process, both on the customer and developer side. Problems with the consistency and completeness can usually only be found this way, e.g. by scrutinizing the requirements as a whole. Formal requirement reviews consist of walking the customer through the system requirements. Two main approaches to prototyping Evolutionary: Iteratively refined prototypes that will eventually be used in the implementation. Throwaway: "Quick and dirty" prototypes that are used only in the requirements engineering process, So-called rapid prototyping is a mix of both approaches, e.g. a partial solution built to help understand the problem. Usually either implement all features of a single function, or all functions with limited features. Not all fit criteria can be tested before the product is delivered, e.g. for non-functional requirements with regards to reliability. The fit criteria should also be reasonably testable, e.g. for a nuclear power plant, "In the case of a reactor melt-down, the system shall reduce the deaths of personnel within a 20 mile radius by at least 80%" Agreed-upon testing criteria become crucial if there are any disagreements with the customer once a system has been delivered. Several different types of checks are required. Review, prototypes and test-case generation are important tools in validating requirements. For large, complex systems, getting all the requirements right is almost impossible, which is why both the requirements and software engineering processes are usually iterative. Purpose The requirements documents is a full description of what the system should do, but not of how it should do it. Users Different stakeholders will use the requirements document in different ways: System customers: Specify the requirements and read them to check that they meet their needs. Customers specify changes to the requirements. Managers: Use the requirements document to plan a bid for the system and to plan the system development process. System engineers: Use the requirements to understand what system is to be developed. System test engineers: Use the requirements to develop validation tests for the system System maintenance engineers: Use the requirements to understand the system and the relationship between its parts. Level of detail Level of detail required depends on a number of factors: IEEE standard structure The IEEE standard 830-1998 provides guidance on the structure of system requirements documents. IEEE standard features The IEEE standard also specifies some general characteristics of the requirements document: Recommendations Develop your own structured notation to describe requirements, e.g. name, description, inputs, outputs, actions, diagrams, etc... And stick to it throughout the entire document. It gives full visibility and secure record of the required behaviour. Facilitates the future development of new systems with similar functionality. Provides information for production of user manuals and other forms of training documentation. It provides a baseline against which functionality can be tested. Ensures correct information is accurately communicated to the developers and facilitates future maintenance. The type of system being developed, i.e. how likely and often it is to be updated and/or extended. The development process used, e.g. in agile processes requirements are added incrementally. The level of external scrutiny, e.g. for safety-critical systems. The type of relationship between the customer and software engineers, e.g. if the system is being developed in-house or by an outside contractor. The diversity of possible users means that the requirements document has to be a compromise between communicating the requirements to customers and defining the requirements in detail for developers and testers. Introduction: Overview of the purpose and scope of the entire system, provide the definitions of all terms, acronyms, and abbreviations used. General description: This section does not state specific requirements, but instead provides a background and context for those requirements, e.g. context models, what functions the system will perform, and the outside constraints on the system. Specific requirements: User and system requirements, both functional and non-functional, e.g. interfaces, functions, and specific constraints. The IEEE standard is very general, but provides a good framework from which to extract a useful structure for a specific case. Correct: Every requirement is actually required by the system. Unambiguous: Every requirement has only one interpretation. Complete: All the significant requirements, whether relating to functionality, performance, design constraints, attributes or external interfaces are included. Consistent: The requirements are all mutually consistent. Ranked: Requirements are given an unambiguous order of priority. Verifiable: All requirements are verifiable and can be tested. Modifiable: Any changes to the requirements can be made easily, completely, and consistently Traceable: The origin of each requirement is clearly specified. Avoid the use of jargon, i.e. you should not need any as the requirements document is a description of what is to be done, and not how. Develop a numbering scheme for your requirements, and use it consistently throughout the document to improve traceability. Be as consistent as possible in style, format, nomenclature, etc... This may be challenging when working as a group, but has a significant effect on the readability of the document. Software engineering for
the Internet About this course What is software engineering Software development process About myself Lecturer in Computer Science since March 2012. Course structure 18 hours of lectures: Monday, Wednesday and Friday of the first two weeks from 09.00-12.00. Group project You will be split into two groups of five people each. Course materials This course is heavily based on Ian Sommerville's "Software Engineering", ninth edition, 2011. Research focused on shared-memory parallel computing, high-performance computing, GPU computing and particle-based simulations. Software engineering is not the focus of my research, but it is something that permeates every larger development effort, be it commercial, academic or leisurely. Independent work on the group project for the third and fourth week, will make myself available on Monday, Wednesday and Friday at 11.00. The subjects covered will be as follows: Introduction: 1 hour, as in now. Requirements engineering: 8 hours. Design and Implementation: 6 hours. Testing and deployment: 3 hours. You will be given a rudimentary description of the requirements for a software project, i.e. the development of a school management system. Your job is to produce the following: A detailed requirements document (24%). A detailed design document (24%). A 30-minute presentation describing the proposed system (12%). An individual self-assessment of your work in this project (40%). All four are due on the Friday of the fourth week, i.e. November 30th. There will be no paper handouts. All the course material is available online, including these slides which can be browsed as they are shown here. A detailed description of the group project and assessment will also be available on DUO. Software development As opposed to programming, software development refers to the entire process of producing software. Software engineering Software engineering is an engineering discipline concerned with all aspects of software production. Main aspects The systematic approach used in software engineering is usually referred to as the software process. System types How the software process is implemented depends heavily on the type of system being developed: The Web During the past ten years, software has evolved from running mainly on local computers and/or closed networks, to services provided via the Internet and web browsers. Software processes A software process is a set of related activities that leads to the production of a software product. Software process models Software process models are simplified representations of a software process. The waterfall model Traditional, plan-driven approach, derived from more general system engineering processes. Incremental development Incremental development is based on the idea of producing an initial implementation and iteratively refining it with the customer. Agile methods In certain fast-moving business environments, it is often practically impossible to derive a complete set of stable software requirements. This includes program specification, design, testing, documentation, deployment, and evolution. Software development usually happens in teams and may span time scales beyond the individual involvement of each team member. The scope, size and impact of software projects can be massive, e.g. banking software, software for managing services such as NHS, or software for the control of nuclear power plants. This involves not just the technical process of software development, but also activities, e.g. customer interaction, project management, and product documentation. Software engineering is related to computer science in that knowledge of the latter is essential for software development, but is not sufficient to successfully tackle large, real-world software projects. In summary, software engineering is the science of applying the concepts of computer science to large-scale, real-world problems. The software process usually consists of four fundamental activities: Software specification: Work with the customers to define what the desired software should do, as well as the constraints on its operation. Software development: Design and develop the actual software. Software validation: The software is tested to ensure that it works correctly and does what the customer wants it to do. Software evolution: Changing customer and environment requirements may lead to the software require changes and updates. Stand-alone applications: Run independently on a single computer, Interactive transaction-based applications: Business systems or web-based e-commerce applications, Embedded control systems: E.g. for appliances or complex machinery, Batch processing systems: E.g. periodic billing systems, Entertainment systems: Compute-intensive gaming systems, Scientific computing systems: Developed by/with scientists for use in their field of research, Systems of systems: Composed of standard and custom software. The use of web browsers and HTML as a common interface greatly simplified the proliferation of online services. Updating and deploying software is much easier, as it usually resides on local servers, and not on the users' computers. Instead of paying for software, people now often pay for the services supplied by a software. Lots of software is now provided for free, but the rest of the software engineering process is often still needed to make it useable. Although there are several different processes, they all include the same four fundamental activities: Software specification: The functionality of the software and constraints on its operation must be defined. Software design and implementation: The software must be produced, meeting the specification. Software validation: The software must be validated to ensure that it does what the customer wants. Software evolution: The software must evolve to meet changing customer needs. Generic models are used not as definitive descriptions, but rather as abstractions to explain different approaches. Different models are not mutually exclusive and can be used concurrently for different parts of larger projects. Extreme programming Extreme programming is probably the best-known agile method. Each phase only starts when the previous has been completed. In practice, though, these phases overlap, feeding information to each other. Required changes to the requirements, design or implementation are only identified and addressed once the system has been released. The different phases of software development are done concurrently, with rapid feedback between activities. Useful when customer requirements are unclear or subject to change. The resulting software can start being used before the final version is complete. Repeated changes can degrade the system as a whole. Agile approaches are incremental development methods in which the increments are small and, typically, new releases of the system are created and made available to customers every few weeks. As opposed to plan-based methods, agile methods value: Individuals and interactions over processes and tools, Working software over comprehensive documentation, Customer collaboration over contract negotiation, Responding to change over following a plan. Incremental development through small, frequent releases of the system. Requirements are based on simple "user stories", e.g. scenarios that describe a specific interaction with, or function of, the system. The customer must be strongly involved with the software development process, e.g. defining acceptance tests for the system. Programmers work in pairs, and several pairs may work concurrently on different user stories. Code must be constantly refactored to avoid degradation over many iterations of the process. Goals A large part of software engineering relies on applying common sense and experience to specific problems. The main goal is to give you an overview of the common problems and the most common types of solutions. This course should also provide you with the vocabulary, both literal and graphical, which is commonly used to describe aspects of software engineering. The assessment serves to verify how well you can apply what you have learned to a specific example problem. Since I'm giving this lecture for the first time, please do let me know if you think there is anything that could be done better or differently! Design and implementation Design and implementation Architectural design Architectural design is the process of producing a model that defines the structure of a system and the relationship between its components. Object-oriented design Application architecture Architectural patterns Object identification Design models Interface design The specification of the interfaces between the components of a system is an important part of any design. Make communication, system analysis, and large-scale reuse more efficient by facilitating discussion and documentation of the design. Architectural design is a creative process, and thus there is no straight-forward approach. Similar systems have similar architectures, and experience with one can help with another. Definition Application architectures describe the structure and organization of particular types of software systems. What they are used for Transaction processing systems Transaction processing systems are designed to process user requests for information from a database, or requests to update a database. Information systems Information systems are systems that interact with a shared database in a more elaborate way than transaction processing systems do. Language processing systems Language processing systems process, e.g. translate or execute, statements written in a natural or artificial language. Definition Architectural patterns are a way of presenting, sharing and reusing knowledge about software systems. Model-View-Controller pattern The Model-View-Controller (MVC) pattern separates the representation of system data (Model) from its presentation (View) and the way the user interacts with it (Controller). Layered architecture In a layered architecture, the system functionality is organized into separate layers, and each layer relies only on the functionality of the layer directly below it. Client-server architecture The client-server architecture is commonly used for the run-time organization of distributed systems in which the functionality of the system is organized into services, each delivered from a separate server. Pipe and filter architecture The pipe and filter architecture is used to model systems in which functional transformations process their inputs and produce outputs. either sequentially or in parallel. Relation to application architectures Application architectures specify what a program does, whereas the architectural patterns specifies how it is done specifically. Although every system is different, common architectural structure can be reused for similar systems. Common architectural structures can be useful in a number of ways: As a starting point: If unfamiliar with the type of system to be designed, the initial design can be based on a generic architecture. As a design checklist: Is the proposed design consistent with the generic architecture? As a form of reuse: Identify similar components between architectures that may be reused from other projects.. As a vocabulary: Common concepts make discussion easier. As an organizational tool: Identify major parts that can be developed concurrently. Application architectures encapsulate the principal characteristics of a class of systems, e.g. transaction processing systems, information systems, or language processing systems. These are rough descriptions of what a system does and how it is organized, i.e. which distinct parts do what. A transaction is a sequence of operations that is treated as a single, or atomic, unit which need to succeed before the transaction is made permanent. Most web-based services are transaction-based system in which a server is polled with an HTTP request and returns some form of data. This is also true of how a bank handles transactions, or an airline manages bookings. The main purpose of such systems is to make data or content accessible, e.g. search engines of any type, or online news sites. Data is usually not returned in its raw form, but may be additionally processed, e.g. sorted, filtered, or aggregated from several sources. Both the query and result data can be of various different types, e.g. text, images, or geographical information. Such systems are commonly used for compiling programming languages into machine-executable code, or parsing HTML for displaying web pages. Despite the different intricacies of each type of input language, the structure of such a system, i.e. a parser, usually relies on the same components. Summary Similar applications have similar architectures. In many cases, these architectures can be reused as a starting point, checklist, source of components, and communication and organization aids. These similarities may not always be entirely obvious. The concept of design patterns was introduced by the so-called "Gang of four", Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides in their 1995 book, and subsequently extended by several other authors. Each design pattern represents a stylized, abstract description of good practice, which has been tried and tested in different systems. Architectural design patterns are one of several families, e.g. creational patterns, structural patterns, and behavioral patterns, of which we will see more later on. Repository architecture As opposed to the MVC and layer patterns, which show how a system is organized, the repository architecture shows how different interacting components can share data. Summary Architectural patterns are a useful abstraction for describing how certain processes will be implemented. The Model component manages the data and its associated operations. The View component receives data from the model for display. The Controller component manages user interaction with the data. Multiple views and controllers can be used for the same data in different contexts. The notions of separation and independence are fundamental to architectural design, as they allow changes to be localized. As long as the interfaces are preserved, the individual layers can be modified or replaced without changing the entire system. This is important, e.g. for hardware-independent architectures. Architectural views It is usually impossible to represent all the relevant information in a single architectural model, which is why we distinguish between 4+1 fundamental architectural views: Logical view: Shows key system abstractions as objects or object classes. Physical view: Shows how the software and hardware are distributed. Development view: Shows how the software is decomposed, i.e. the breakdown of the software into individual components, for development. Process view: Shows how, at run time, the system is composed of interacting processes. Most information systems with large amounts of data are organized around a shared database or repository. Instead of interacting directly with each other, each part of the system interacts only via the repository. Components can thus be made completely independent of each other, as long as they adhere to the same data formats. The clients and servers need not be distributed physically, but may all reside on the same machine. Interactions usually follow simple request-reply protocols. The capacity of such systems can be extended by replicating servers to handle clients concurrently. Often used for simple processes or automatic data processing systems, e.g. embedded systems, or billing systems. The name comes from the UNIX command line, where the output of one program can be "piped" directly as the input to another program. The information system architecture described earlier could be implemented both using a MVC pattern or a layered architecture pattern. Different patterns provide different views of the systems, e.g. how its data is structured or how it reacts to inputs. Whereas Application architectures describe what a system does, architectural patterns describe how this is done. Design Document The design process The object-oriented design process involves designing object classes and the relationships between these classes. Object oriented design vs. programming Object-oriented programming is a programming paradigm, or concept, which attempts to unify data and methods on said data, into objects. Design patterns This is a creative process, and there is therefore no clear-cut, sequential recipe that can be followed. The following only describes the steps that need to be taken, but these are taken in no particular order, or concurrently. Iterative refinement is commonly used, i.e. start with a high-level abstraction of the main objects in the system and successively break them down into their respective parts to add detail. Knowledge and intuition from Computer Science and programming will help you through the process. As such, object-oriented design is not restricted to object-oriented programming languages such as Java or C++. For example, the Linux GNOME Desktop is built using GTK+, an object-oriented library written in plain C. Fully object-oriented languages are required in systems where features such as dynamic polymorphism are used. Object identification By the time you reach this stage, you should have some idea about the essential objects in the system you are designing. Methodologies Several methodologies for the systematic identification of object classes have been described: Example: Initial model From the user requirements of a software system to manage a school: Example: Refinement Using more detailed user and system requirements, the initial set of objects can be refined and/or extended: Example: Reuse Often, when objects have been broken-down to their individual components, re-usable object types may emerge: During the design phase, you will re-evaluate and refine these ideas. The system models developed in the requirements phase, e.g. the use cases, offer a good starting point for identifying the main system components. Objects can be identified hierarchically, e.g. higher-level system objects can themselves be decomposed into any number of smaller, interacting objects. Grammatical analysis: Requirements specified in natural language, e.g. using nouns, adjectives and verbs, can be converted into objects, attributes, and operations, respectively. Tangible objects: Use knowledge of the application domain, e.g. the concepts or "things" as they are described therein. Scenario-based analysis: In each scenario in the requirements, each part can be considered a separate object. Since none of these methods alone is sufficient to identify all objects at all levels of detail, usually several methods will be used concurrently. The system provides a tool to manage all school functions, i.e. facilities, classes and people. From this description, we can extract an initial set of objects: Facilities: The physical infrastructure of the school, Classes: An abstract domain-specific unit, People: System actors involved with the school. Main concepts During the requirements engineering phase, we already encountered the use of UML to describe system models. Structural models Structural models describe the static structure of a system using object classes and their relationships. Subsystem models Subsystem models are used to represent high-level logical groupings of objects into coherent subsystems. Sequence models Sequence models show the sequence of interactions between objects. State machine models If any of the objects in the system have some notion of state, state machine models can be used to describe how they go from one state to the other in response to inputs and/or events. Such models exist at different levels of details, or levels of abstraction, for different intended audiences, e.g. end users or developers. Design models are similar to system models, yet differ in that they describe how something is done, as opposed to what is done. These models show how the objects defined in the object identification phase interact with, or relate to, each other. The most important features are: Generalizations, i.e. inheritance, for similar object types, Encapsulation, i.e. which object classes contain references to other object classes. Aggregation, i.e. which object classes are compositions of other classes. Usually modeled using UML class diagrams. These models are more organizational in nature, i.e. they show which parts of the system can be modeled or designed as a single entity. In our example system, all data pertaining to facilities, i.e. buildings and rooms, is grouped into a single package. As opposed to the structural and subsystem models, the sequence model is a dynamic model, e.g. it shows how the objects react to inputs or changes of state. As within the system models, UML sequence diagrams are used, yet now with specific object classes and method names to describe each interaction in terms of how it is implemented. Such models should be produced for each significant interaction within the system, e.g. for each use case. This is also a dynamic model, but as opposed to sequence models, it describes only what happens within a given object. Since most of the objects in a system are usually relatively simple, not all of them will require a state diagram. Useful for checking for inconsistencies, e.g. what effect a method or input will have for any given state. Once interfaces have been specified, different parts of the system can be developed concurrently. The interface definition should not include details of the data representation, e.g. accessing an object's fields should be implemented via "getters" and "setters", such that changing the data model does not affect the interface. Interfaces are usually considered to be calling conventions, i.e. function names, parameters, and return values, although some languages provide explicit interface definitions. Classification Object-oriented design patterns are usually grouped into three categories: Adaptor pattern Also referred to as wrapper or translator pattern, the adaptor pattern is used to translate the interface of an object, e.g. into a more convenient or standardized interface. Facade pattern The facade pattern describes an object, referred to as the facade object, which provides a unique and/or simplified interface to a larger, more complex subsystem. Decorator pattern The decorator pattern describes a mechanism for adding functionality to an existing object at runtime. Factory method pattern The factory method pattern is a creational pattern that specifies factory objects whose purpose is to generate objects of a given class. Abstract factories pattern The abstract factory pattern is similar to the factory pattern, but differs in that it provides a class whose sole purpose is to produce a set of objects of the correct type. Singleton pattern The role of the singleton pattern is to ensure that only one instance of a given object class exists. Iterator pattern The iterator is a behavioural pattern which provides a mechanism, similar to a for-loop, for iterating over a collection of objects. Observer pattern The observer pattern represents a method to receive notifications from an object, e.g. on a change of state or on activity. Strategy pattern The strategy pattern implements a form of polymorphism for functions, i.e. an object class is used to encapsulate a single functionality as a method which is implemented differently by each of its subclasses. Template pattern The template pattern is a way of representing entire algorithms with customizable and/or replacable parts. Creational patterns: Describe how instances of objects are created to satisfy specific user requests. Structural patterns: Describe different models for the relationship between object classes. Behavioural patterns: Describe how objects communicate between each other or react to inputs. As with architectural design patterns, object oriented design patterns represent experience and best practice in a general and reusable way. This is often used when incorporating objects or functionality from standard libraries that use an interface different to the ones used in the system. Adaptor classes are understood to only pass on, and if necessary translate, the input and output, i.e. no additional functionality is added. This pattern hides the complexity of a larger subsystem behind a simpler and potentially reduced interface. Any changes in the design or interfaces within the subsystem only has to be adapted in the facade object. Can also be used to aggregate the functionality of several different subsystems. Instead of defining a new object class, the object is wrapped in another object with the same interface, which provides additional functions. Multiple decorators can be added on top of each other, thus accumulating extra functionality. This is how I/O-streams are created/handled in Java! This can be of use when working with an interface that provides, for example, an abstract tree which can be either a binary tree or an AVL tree. An abstract factory could then provide the correct type of node for each data structure. This can be used e.g. for cross-platform GUIs, in which abstract factories are used to create the corresponding widgets for each platform. The +1 view consists of scenarios which may embody the other views. Ideally, a constructor or factory for such a singleton object should always return the same instance. This, however, is non-trivial for many object oriented languages, e.g. in Java, and requires some extra machinery. Since the constructor is private, it can not be called from outside the object, and thus Singleton.getInstance() has to be used to retrieve the single instance. Iterators usually have only two functions, "hasNext()" which determines if there are still objects over which to iterate, and "next()" which provides a pointer to the next object. Iterators are usually generated using factories, i.e. the object class storing the data, e.g. an array, linked list, or tree, provides a method which returns a concrete iterator specific to that class. Observable objects must provide methods to register, unregister, and notify a set of observer objects. The observer object itself provides a function which is called whenever there is a notification. In the MVC architectural pattern, the View object can be implemented as an observer that reacts to notifications from the Model. It is up to the calling class to pick the correct strategy object, unless it is combined with the factory pattern to automatically produce the correct strategy for a given problem. In programming languages that support function pointers, the encapsulation in an object class is not required. As with the strategy pattern, an object class is used only to encapsulate specific behaviours, which is not necessarily required for languages that support function pointers. The individual steps can be declared as "virtual" or have default implementations. Inversion of control principle, e.g. the "don't call us, we'll call you", or Hollywood principle. Purpose The software design document shows how the software system will be structured to satisfy the requirements identified in the software requirements specification. Terminology The IEEE 1016-1998 "Recommended Practice for Software Design Descriptions" uses the following terminology when referring to software designs: Design entities A design entity is an element of a design that is structurally and functionally distinct from other elements and that is separately named and referenced. Entity attributes A design entity attribute is a named characteristic or property of a design entity, i.e. it provides a statement of fact about the entity. Design views A design view is a subset of design entity attribute information, i.e. entities and their attributes. Document structure The IEEE 1016-1998 standard specifies six main document sections: In a complete software design document, each requirement must be traceable to one or more design entities. In essence, the design document becomes a detailed blueprint for the implementation activity. It is a translation of requirements into a description of the software structure, software components, interfaces, and data necessary for the implementation phase. Design entity: An element (component) of a design that is structurally and functionally distinct from other elements and that is separately named and referenced. Entity attribute: A named characteristic or property of a design entity. It provides a statement of fact about the entity. Design view: A subset of design entity attribute information that is specifically suited to the needs of a software project activity. Although entities are different in nature, they possess common characteristics, e.g. name, purpose, and function, and common relationships among entities, e.g. interfaces or shared data. Entities can exist as a system, subsystems, data stores, modules, programs, and processes. Design entities result from a decomposition of the software system into separate components that can be considered, implemented, changed, and tested with minimal effect on other entities. Entity attributes can be thought of as questions about design entities where the answers to those questions are the values of the attributes. The IEEE 1016-1998 standard defines the following necessary attributes: Identity: A unique and descriptive name. Subordinates: The identification of all entities composing this entity. Function: A statement of what the entity does. In the case of a data entity, this attribute shall state the type of information stored or transmitted by the entity. Purpose: Provides the rationale for the creation of the entity, i.e. designates the specific functional and non-functional requirements that make this entity necessary. Type: Describes the nature of the entity, e.g. subprogram, module, procedure, process, or data store. Dependencies: A description of the relationships of this entity with other entities, including the nature of that relationship. Data: A description of data elements internal to the entity. Processing: A description of how the entity implements its functionality, e.g. the algorithms or the workflow used. Resources: A description of the elements used by the entity that are external to the design, e.g. physical devices or operating system services. Interface: A description of how other entities interact with this entity, e.g. what methods and how they are called. Different views provide details on different aspects of a software project. Decomposition description Scope: The decomposition description records the division of the software system into design entities, i.e. how the system has been structured and the purpose and function of each entity. Dependency description Detailed description Interface description Entity attributes: Descriptions for identification, type, purpose, function, and subordinates should be included for all entities in this design view. Use: The decomposition description can be used by designers and maintainers to identify the major design entities of the system for purposes such as determining which entity is responsible for performing specific functions and tracing requirements to design entities. Representation: UML class diagram, structured natural language. Scope: The dependency description specifies the relationships among entities, i.e. identifies the dependent entities, describes their coupling, and identifies the required resources. Entity attributes: Descriptions for identification, type, purpose, dependencies, and resources should be included for all entities in this design view. Use: The dependency description provides an overall picture of how the system works. Representation: Structure charts, data flow and transaction diagrams Scope: The entity interface description provides everything needed to know to correctly use the functions provided by an entity. Entity attributes: Descriptions for identification, function, and interfaces should be included for all entities in this design view. Use: The interface description serves as a binding contract among designers, programmers, customers, and testers, providing them with an agreement needed before proceeding with the detailed design of entities. Representation: Interface files, parameter tables. Scope: The detailed design description contains the internal details of each design entity. Entity attributes: Descriptions for identification, processing, and data should be included for all entities in this design view. Use: This description contains the details needed by programmers prior to implementation, e.g. detailed descriptions of algorithms or data layout that are not sufficiently well described by other views. Representation: Natural language, pseudo-code, tables. Introduction and references The software design document introduction should contain the following information: Decomposition description The decomposition description describes the division of the software system into design entities, e.g. how the system has been structured, and the purpose and function of each entity. Dependency description The dependency description specifies the relationships among entities, i.e. it identifies the dependent entities, describes their coupling, and identifies the required resources. Interface description The entity interface description provides everything designers, programmers, and testers need to know to correctly use the functions provided by an entity. Detailed design This final section should contain any additional information which was not provided in the previous sections. Introduction References Decomposition description Dependency description Interface description Detailed description Purpose: State the purpose of the design document, as well as the system objectives and goals. Scope: Overview of what the software will and will not do, e.g. what the main requirements are. Definitions: Technical terms, acronyms and abbreviations. Document information: Date published, authors, change history. Overview: Brief description of how the rest of the document will be structured. You should make different subsections for each type of entity, e.g. modules, concurrent processes, or data. The decomposition description is also used for specifying how specific functional requirements are mapped to the entities. Design entities can be grouped into major classes to assist in locating a particular type of information and to assist in reviewing the decomposition for completeness. Defines the strategies for interactions among design entities and provides the information needed to easily perceive how, why, where, and at what level system actions occur. Separate subsections for dependencies between modules, between processes, and between data, e.g. in a database. This description includes the details of both external and internal interfaces not provided in the software requirements specification. You should make a separate subsection for every entity that has an interface. Each entity interface description should contain everything another designer or programmer needs to know to develop software that interacts with that entity. Not every entity will necessarily require detailed design information! As these details do not fit in the common views and their representations, natural language is usually the most convenient way of describing them. Hidden detail often applies to data, e.g. consistencies in databases, specific number or data formats, or their representation when stored. Summary The software design document is a detailed description of a software design, along with the rationale used to develop it. The IEEE 1016-1998 standard specifies common entities, attributes a views which can be used to describe all aspects of the design. The IEEE 1016-1998 standard should be seen as a set of guidelines: Every project will have a different set of stakeholders with different levels of understanding, and you should tailor your document to your project and environment. The IEEE 1016-1998 standard has been revised, i.e. 1016-2009, but you should stick to the less strict original. Software design process Whereas the requirements phase was concerned with what a software system does, the design phase deals with how it will do so. The goal of the design phase is to produce a sufficiently complete description of the system such that it can be implemented. This is a creative process, and as such there is no fixed methodology with which to proceed. Although distinct tasks exist, they are strongly correlated, and the order in which they are processed is by no means fixed. The following slides rely heavily on UML and object oriented programming techniques, whereby the former is not used rigorously, and the latter does not imply the use of an object oriented programming language. Implementation issues At this stage, i.e. with a complete design documentation, implementation is only a technical task. A detailed discussion of good programming practice would go far beyond the scope of this lecture, and is more pertinent to programming in general than to software engineering. The more effort we put into the design, the fewer decisions we will have to make during implementation. We can apply certain concepts from the design phase to the implementation phase, most importantly code reuse at all levels: At the abstraction level, the object level, the component level, and the system level. Software testing The goal of testing is to discover problems with the software before it is put to use. Reviews and Inspections Development testing Development testing is a set of defect testing activities carried out by the developer teams who wrote the software themselves. Validation testing In validation testing, there are two distinct goals, or questions: Testing serves two main purposes: Validation: Verify that the software meets the customer requirements, Defect testing: Verify that the software does not contain incorrect or undesirable behaviour. Testing can only show the presence of errors, not their absence. Definition Software inspections and reviews consist of a systematic analysis that can be used to check all aspects, at all steps, of the software process, e.g.: Advantages over testing Since it is hard to distinguish if an undesired program behaviour is the cause of one or several errors, testing has to deal with errors one at a time, whereas inspection deals with all potential errors at once. Disadvantages over testing Since inspections and reviews are static tools, they may not uncover problems that arise from unexpected interactions between objects in the system, e.g. concurrency problems in parallel systems. System requirements, System design models, Program source code, The proposed system tests. Inspections and reviews are "static" techniques, i.e. the code does not need to be executed for verification. Mostly focus on the source code, but since it is a static process, it can be performed on any readable part of the software. Incomplete versions of the system can be inspected, whereas testing would require constructing a fake testing environment to simulate missing components. Inspections and reviews can consider broader quality attributes which may be difficult to evaluate in defect testing. Systematic nspections and reviews will normally consider all parts of the code preemptively, thus leaving no dark corners in which bugs can hide. Although these problems are hard to track down when defect testing or debugging, they are also very difficult to imagine and thus anticipate. Problems relating to system performance are also quite difficult to anticipate, whereas profiling will give an exact map of where in the software performance is lost. Inspections and review require lots of time, and require people who have not worked on a component to test it, making it expensive for small developer teams. Checklists To facilitate inspections and reviews, checklists of the most common types of faults are used, e.g.: Data faults: Uninitialized variables, unnamed constants, array bounds, buffer/memory overflows, data structure consistency. Control faults: Conditional statements, loop termination criteria, statement bracketing, completeness of if-then-else or case statements. I/O faults: Unexpected inputs, assignment of all output variables. Interface faults: Parameter count, type, and order, potential side effects. Exception faults: Catch all possible exceptions or return values. Unit testing Component testing System testing Systems testing is similar to components testing, yet applied to the system as a whole. For critical systems, the tests should be written by somebody who was not involved with development of the code being tested. Three levels of granularity: Unit tests: Test individual objects, Component tests: Test interfaces between objects within components, System tests: Test the system as a whole. Definition Unit testing is the process of testing individual program components, such as methods or object classes. What to test Unit tests should cover all aspects of an object's behaviour: When to test Unit tests should be automated whenever possible, e.g. by using a test automation framework that compiles and executes all tests automatically. Choosing test cases Since developing and running unit tests can be quite time consuming, the tests themselves should be as effective as possible, e.g.: Benefits Early defect detection: If tests are implemented before, or as soon as, a component is implemented, problems can be caught before they affect other parts of the system. Guidelines Choose inputs that force the system to generate all error messages, e.g. do everything that the interface definition says you shouldn't. This is the lowest level of testing, used to verify that each part of a system works as specified. These tests may be formulated, before, during, or after the design and/or development of the component. Unit tests are usually written by the developers themselves, but may also be used as a form of inspection and revision. Each unit test is usually a function that tests one particular aspect of the component in question. Test all operations associated with the object, e.g. constructors and methods. Set and check the value of all attributes associated with the object. Put the object in all possible states, and test all possible transitions from one state to the other. Unit tests should cover not only all correct uses of the object's interfaces, but also incorrect uses. Check for failures, e.g. that illegal operations fail the way they should. Ideally, unit tests should be run whenever any part of an object is modified and/or extended. Tests are not inherited, e.g. each subclass of an object class needs its own tests. Automated tests usually adhere to the same structure: Setup, test, and assert. If the unit tests are created by the developer, appropriate tests should be added as soon as additional features or functionality are added to the object such that they can be tested incrementally. The tests should show that, when used as expected, the component does what it is supposed to do, e.g. test using normal inputs. If there are any defects in the component, they will be revealed by the unit tests, e.g. test using abnormal inputs. The coverage of unit tests can be optimized by considering which sets of inputs will lead to different behaviour in the object, and make a test for each such set, and/or at the limits between sets. Verify modifications: If tests are run whenever a component is modified, it can be used to verify unanticipated side effects. Simplify debugging: When searching for the source of defects in later testing stages, unit tests help exclude potential problem sources. Design and documentation: If the unit tests are specified beforehand, they provide a template for the component's design and a source for documenting its use. Mock objects and harnesses Not all functional aspects of a component or object can be tested in complete isolation, e.g. functions which rely on other objects as parameters, or interactions with other objects. In such cases, in order to simplify the testing, mock objects are created which simulate the interacting objects to the degree necessary for the particular test. A set of objects simulating the environment in which the tested object exists and in which the tests are run is referred to as a test harness. Definition Component testing deals with composite components, i.e. components consisting of several interacting objects. Interface types The objects in a component do not always interact in the same way, and different types of interactions can lead to different types of errors. Error types Interface misuse: Parameters to a function or method may be of the wrong type or be given in the wrong order. Guidelines Examine the code and design to make sure you test all interfaces. The functionality of these objects as a component is accessed through a defined component interface, which should be tested against its specification, as in unit testing. Additionally, though, we now need to make sure that: The component functions correctly as a whole. The interactions between the objects within the component function correctly. Parameter interfaces: Data or control is passed to an object by changing or setting its internal values and/or parameters, or by calling its methods. Shared memory interfaces: Data is exchanged between objects by storing it in an area of memory accessible by both. Procedural interfaces: Sets of procedures which can be called by the components, e.g. individual steps of a process or utility functions. Message-passing interfaces: Using observers or a client-server architecture, data and control are transmitted using messages. Interface misunderstanding: The interface is used in a formally correct way, but with the wrong intent, i.e. the expected behaviour does not match the actual functionality, or the data provided does not satisfy additional constraints. Timing errors: When using shared memory or message passing, the producer and consumer of data or an event may be out of sync, e.g. the consumer misses the data/event supplied by the producer. Such interfaces require care or additional machinery to get the synchronization right. Essentially, we are testing the interfaces between interacting objects. Choose tests that take both normal and extreme cases in consideration. Test the outside interfaces with invalid parameters. For procedural interfaces, provide procedures that will fail, e.g. to test if the component accounts for this. For shared memory or message-passing interfaces, use stress-testing, i.e. flood the system with messages and/or data, as this will quickly reveal timing or synchronization problems. It differs in that this may also include interfaces to external components, or components by others, e.g. libraries. The system will produce emergent behaviour, both expected and unexpected, that cannot be tested within the individual components. Since the range of possible interactions usually grows exponentially with the system size, it is not possible to test them all systematically. Use cases or process models, described in the requirements, usually provide an effective set of functionality to be tested. Verification vs. validation The aim of verification is to check that the software meets its stated functional and non-functional requirements. Release testing User testing User testing is the final stage in the testing process in which actual users provide input and advice. Validation: Are we building the right product? Verification: Are we building the product right? In both cases, we are concerned with verifying that the software meets its requirements. These tests are usually done during, and after development, by developers, testers, and sometimes by the actual end-users. The aim of validation is to check that the software meets the customers expectations, which may not be adequately reflected in the requirements. Whether a software product is "fit for purpose" depends on several factors: Purpose: How critical is reliability in the domain of application, and what is the level of confidence required? Expectations: What tradeoff between reliability and availability are users willing to accept? Marketing: Is releasing low-reliability beta versions of the final product necessary for publicity? Definition Release testing is the process of testing a system that is intended for use outside of the development team, e.g. it will be released to the public. Requirements-based testing Remember that one of the criteria for good requirements is that they are verifiable, or testable. Scenario testing Scenarios are by-products of the requirements engineering process that describe ways in which the system might be used. Performance testing Performance testing consist of verifying that the system can process its intended load. This differs from development testing in two important aspects: A separate group, which has not been involved with the development, will be responsible for release testing. The focus is on checking the requirements, and not on finding bugs. The main goal is to provide evidence to the customer that the system is fit for purpose, e.g. it meets the customers expectations. In this process, the system is usually treated as a "black box", i.e. the testers have no information on how it is built, only on what it should do. Requirements-based testing is a systematic approach in which each requirement is considered and a set of tests is derived for it. Each requirement may need several individual tests, e.g. "Administrative staff should be able to add, delete and modify student records": Basic tests to add, delete and modify student records. Tests to add two identical students. Tests to modify a student such that it is identical to another student. Scenarios may be taken from the requirements directly, or developed from other functional requirements. Scenarios should be realistic: Recall that we are validating and verifying the requirements, not looking for bugs. Scenarios should be written as credible and fairly complex user stories, and should involve several correlated but different types of interactions with the system. Scenarios should be played through more than once with minor variations, e.g. making different deliberate mistakes. This usually consists of increasing the system load until it breaks or becomes otherwise unusable. Performance tests are usually run with automatically generated inputs, e.g. random transactions in a transaction management system. Although the inputs are random, they should match the characteristics of real data, e.g. ratio of types of transactions. By forcing the system to fail, its robustness features, e.g. recovery time from failure, can also be evaluated. We usually distinguish between three types of user tests: Alpha testing: Selected users test the software directly with the developers, e.g. at the developers site. Beta testing: A release of the software is provided to users who may relay their issues to the development team. Acceptance testing: The customer tests the system and decides whether or not it will be accepted and deployed. The acceptance criteria and tests are usually derived along with the system requirements and should, ideally, cover the latter. Design inputs that cause input buffers to overflow, e.g. make your objects deal with overflows instead of guessing a maximum size. Repeat the same input or series of inputs numerous times, e.g. verify that the objects' operations don't have hidden side effects. Force invalid outputs to be generated, e.g. how does your component deal with operations that fail? Force computation results to be too large or too small, e.g. make sure the output buffers don't overflow.
Full transcript