SOFTWARE accommodated at relatively low cost System prototyping: A version of the Deployment, Implementation View. User Interface Prototype.

version of the Deployment, Implementation View. User Interface Prototype. Software ⏵Pros: Allows the data to change independently of its representation and
▼ Software = Computer programs and associated documentation Software system or part of the system is developed quickly to check the customer’s Deliverables vice versa. Supports presentation of the same data in different ways with
products may be developed for a particular customer or may be developed for requirements and the feasibility of design decisions (This supports change ⏵Evolution: Bugs and Issue Tracking Reports, Change Requests and Change changes made in one representation shown in all of them.
a general market. Good software: Maintainability, Dependability and security, anticipation.) Incremental delivery: System increments are delivered to the Logs, Release Notes, Metrics and Performance Reports, Code Reviews and ⏵Cons: Can involve additional code and code complexity when the data
Efficiency, Acceptability customer for comment and experimentation (This supports both change Documentation, Bugs and Issue Tracking Reports, Risk Management model and interactions are simple.
∎ Software product: avoidance and change tolerance) Documents ▼Layered architecture: Organizes the system into layers with related
▼Generic products: Stand-alone systems that are marketed and sold to any ∎ PLAN-DRIVEN AND AGILE PROCESSES. Plan-driven processes are ▼ Testers: functionality associated with each layer. A layer provides services to the layer
customer who wishes to buy them. The specification of what the software processes where all of the process activities are planned in advance and ⏵Validation: Master Test Plan: Target Test Items, Environmental Needs, above it so the lowest-level layers represent core services that are likely to be
should do is owned by the software developer and decisions on software progress is measured against this plan. In agile processes, planning is Responsibilities, Staffing. Test Cases. Test Report: Testing Summary used throughout the system.
change are made by the developer. incremental and it is easier to change the process to reflect changing customer Report, Bug Report ⏵Use when: Building new facilities on top of existing systems; The
▼ Customized products: Software that is commissioned by a specific requirements. In practice, most practical processes include elements of both ▼ Stakeholders: End-users, managers, engineers involved in maintenance, development is spread across several teams with each team responsible for a
customer to meet their own needs. The specification of what the software plan-driven and agile approaches. There are no right or wrong software domain experts, trade unions, etc. layer of functionality; There is a requirement for multi-level security.
should do is owned by the customer for the software and they make decisions processes. PROJECT MANAGEMENT
on software changes that are required. ⏵Pros: Allows replacement of entire layers so long as the interface is
∎ WATERFALL (Plan-driven): ▼ Concerned with activities involved in ensuring that software is delivered
∎ Software Engineering: ▼ Description: Separate and distinct phases of specification and maintained. Redundant facilities (e.g., authentication) can be provided in
on time and on schedule and in accordance with the requirements of the each layer to increase the dependability of the system.
▼ SE is an engineering discipline that is concerned with all aspects of development. In principle, a phase has to be complete before moving onto the organizations developing and procuring the software. Is needed because
software production from the early stages of system specification through to next phase (organized in sequence). ⏵Cons: In practice, providing a clean separation between layers is often
software development is always subject to budget and schedule constraints
maintaining the system after it has gone into use. ▼ Pros: (ChatGPT) Clear and Well-Defined Phases; Predictable Timeline difficult and a high-level layer may have to interact directly with lower-level
that are set by the organization developing the software. Good management
▼ Some fundamental principles apply to all types of software systems, and Costs; Comprehensive Documentation; Minimal Customer Involvement; layers rather than through the layer immediately below it. Performance can be
cannot guarantee project success. However, bad management usually results
irrespective of the development techniques used: Systems should be Early Detection of Issues; Suitable for Stable Technologies; Resource a problem because of multiple levels of interpretation of a service request as
in project failure.
developed using a managed and understood development process. Of course, Allocation it is processed at each layer.
▼ Universal management activities
different processes are used for different types of software; Dependability and ▼ Cons: Difficulty of accommodating change after the process is underway. ▼Repository: All data in a system is managed in a central repository that is
⏵Project planning: Project managers are responsible for planning, accessible to all system components. Components do not interact directly,
performance are important for all types of system; Understanding and Inflexible partitioning of the project into distinct stages makes it difficult to estimating and scheduling project development and assigning people to tasks. only through the repository.
managing the software specification and requirements are important; Where respond to changing customer requirements.
⏵Reporting: Project managers are usually responsible for reporting on the ⏵Use when: There is a requirement for multi-level security. You have a
appropriate, you should reuse software that has already been developed rather ▼ Used when: Only appropriate when the requirements are well-understood
than write new software. General problems affecting the and changes will be fairly limited during the design process. Mostly used for progress of a project to customers and to the managers of the company system in which large volumes of information are generated that has to be
software Heterogeneity; Business and social change; Security and trust; large systems engineering projects where a system is developed at several developing the software. stored for a long time. You may also use it in data-driven systems where the
Scale sites ⏵Proposal writing: Project managers write a proposal to win a contract to inclusion of data in the repository triggers an action or tool.
∎ SE vs. CS: CS focuses on theory and fundamentals. Software engineering carry out an item of work. The proposal describes the objectives of the ⏵Pros: Components can be independent—they do not need to know of the
is concerned with the practicalities of developing and delivering useful project and how it will be carried out. existence of other components. Changes made by one component can be
software. ⏵Risk management: Project managers assess the risks that may affect a propagated to all components. All data can be managed consistently (e.g.,
∎ SE vs. System engineering? System engineering is concerned with all project, monitor these risks and take action when problems arise. backups done at the same time) as it is all in one place.
aspects of computer-based systems development including hardware, ⏵People management: Project managers have to choose people for their ⏵Cons: The repository is a single point of failure so problems in the
software and process engineering. Software engineering part this more team and establish ways of working that leads to effective team performance. repositories affect the whole system. May be inefficiencies in organizing all
general process ▼ PROJECT MANAGEMENT NECESSARY: Projects always have communication through the repository. Distributing the repository across
SOFTWARE PROCESSES budget and schedule constraints. Good management cannot guarantee project several computers may be difficult.
∎ Software process: A structured set of activities required to develop a success. However, bad management usually results in project failure. ▼Client–server: In a client–server architecture, the functionality of the
software system. Software process model: Is an abstract representation of a ▼ SUCCESS CRITERIA: Deliver on time; Costs within budget; Meets system is organized into services, with each service delivered from a separate
process; Presents a description of a process from some particular perspective customer expectations; Well-functioning team. server. Clients are users of these services and access servers to make use of
▼4 fundamental activities of software process: ∎ INCREMENTAL (Plan-driven or Agile): ▼ INFLUENCE FACTOR: Company size; Software customers; Software them.
▼ Description: Specification, development and validation are interleaved.
⏵Process activity definition: Real software processes are interleaved size; Software type; Organizational culture; Software development processes. ⏵Use when: Data in a shared database has to be accessed from a range of
▼ Pros: The cost of accommodating changing customer requirements is ∎ NON-FUNCTIONAL REQUIREMENTS:
sequences of technical, collaborative and managerial activities with the locations. Load on a system is variable.
reduced (analysis & document). Easier to get customer feedback on the ▼ Speed (Processed transactions/second, User/event response time, Screen
overall goal of specifying, designing, implementing and testing a software ⏵Pros: Servers can be distributed across a network. General functionality
development work that has been done. More rapid delivery and deployment refresh time): The system must provide a response to user input within 300
system. can be available to all clients and does not need to be implemented by all
of useful software to the customer is possible. milliseconds under normal load conditions. The login process should
⏵Specification: The process of establishing what services are required and ▼ Cons: The process is not visible: Managers need regular deliverables to services.
the constraints on the system’s operation and development; Requirements complete within 2 seconds, regardless of the number of concurrent users.
measure progress. System structure tends to degrade as new increments are ▼ Size (Mbytes, Number of ROM chips, Maximum Concurrent Users): The ⏵Cons: Each service is a single point of failure so susceptible to denial of
engineering process: Feasibility study: Is it technically and financially added unless time and money is spent on refactoring. service attacks or server failure. Performance may be unpredictable because it
feasible to build the system?; Requirements elicitation and analysis: What application must support a minimum of 1000 concurrent users without
▼ Used when: Complex Projects: complex systems cannot be degradation in performance. The system should scale to accommodate up to depends on the network as well as the system. Maybe management problems
do the system stakeholders require or expect from the system?; comprehensively understood or planned upfront. Requirements are not if servers are owned by different organizations.
Requirements specification: Defining the requirements in detail; 10,000 users during special events.
completely clear or may change over time. There's a need for rapid delivery ▼ Ease of use (Training time, Number of help frames, User Interface ▼Pipe and filter: The processing of the data in a system is organized so that
Requirements validation: Checking the validity of the requirements and early feedback. each processing component (filter) is discrete and carries out one type of data
⏵Design and implementation: The process of converting the system Responsiveness): The user interface must respond to user interactions within
200 milliseconds to provide a smooth and responsive experience. Dropdown transformation. The data flows (as in a pipe) from one component to another
specification into an executable system; for processing.
menus and buttons should react to clicks and selections without noticeable
⬗ Software design: Design a software structure that realizes the delay. ⏵Use when: Commonly used in data processing applications (both batch-
specification; Architectural design: identify overall structure of the system, ▼ Reliability (Mean time to failure, Probability of unavailability, Rate of and transaction-based) where inputs are processed in separate stages to
principal components, their relationships and how they are distributed; failure occurrence, Availability, Backup and Recovery): Automated daily generate related outputs.
Interface design: define the interfaces between system components. backups should be performed with a retention period of at least 30 days. Data ⏵Pros: Easy to understand and supports transformation reuse. Workflow
Component selection and design: search for reusable components. If recovery from backups should be achievable within 4 hours, minimizing data style matches the structure of many business processes. Evolution by adding
unavailable, design how it will operate. Database design: design the system loss. transformations is straightforward. Can be implemented as either a sequential
data structures and how these are to be represented in a database. ▼ Robustness (Time to restart after failure, Percentage of events causing or concurrent system.
⬗ Implementation: Translate software design into an executable program. failure, Probability of data corruption on failure, Concurrency and Thread ⏵Cons: The format for data transfer has to be agreed upon between
The software is implemented either by developing programs or by Safety): The system should handle concurrent access to shared resources communicating transformations. Each transformation must parse its input and
configuring an application system. Programming is an individual activity ∎ REUSE-ORIENTED (Plan-driven or Agile): without causing data corruption, deadlocks, or race conditions. Critical unparse its output to the agreed form. This increases system overhead and
with no standard process. Debugging is the activity of finding program faults ▼ Description: The system is assembled from existing components. Reused sections of code should be synchronized appropriately to ensure thread safety. may mean that it is impossible to reuse functional transformations that use
and correcting these faults. Closely related and may be interleaved. elements may be configured to fit requirements. Based on systematic reuse ▼ Portability (Percentage of target dependent statements, Number of target incompatible data structures.
⏵Validation: Checking that it does what the customer wants; Involves where systems are integrated from existing components or COTS systems, Browser Compatibility): The web application should work ∎ OOD: Define the context and modes of use of the system; Design the
checking and reviewing processes and system testing Verification and (Commercial-off-the- shelf) systems. consistently across various browsers, such as Chrome, Firefox, Safari, and system architecture; Identify the principal system objects; Develop design
validation (V & V) is intended to show that a system conforms to its ▼ Pros: Reduced costs and risks as less software is developed from scratch. Edge. Key functionalities should be accessible and functional on both models; Specify object interfaces.
specification and meets the requirements of the system customer. Testing is Faster delivery and deployment of the system. desktop and mobile browsers. UI DESIGN
the most commonly used V & V activity. System testing involves executing ▼ Cons: Requirements compromises are inevitable: this may lead to a ∎ INTERVIEW: Interviewers need to be open-minded without ▼ Purpose: User Interface (UI) Design focuses on anticipating what users
the system with test cases that are derived from the specification of the real system that does not meet the real needs of users. Loss of control over preconceived ideas of what the system should do. You need to prompt the might need to do and ensuring that the interface has elements that are easy to
data to be processed by the system. evolution of reused system elements user to talk about the system by suggesting requirements rather than simply access, understand, and use to facilitate those actions.
Testing stages: Development or component testing: Individual components ▼ Use when: Reuse is now the standard approach for building many types of asking them what they want. ▼ Principles: UI design must take account of the needs, experience and
are tested independently; Components may be functions or objects or business systems. ARCHITECTURE DESIGN capabilities of the system users. Designers should be aware of people's
coherent groupings of these entities. System testing: Testing of the system as ∎ ROLES OF PERSON: ▼ Model-View-Controller: Separates presentation and interaction from the physical and mental limitations (e.g. limited short-term memory) and
a whole. Testing of emergent properties is particularly important. Acceptance ▼ Developers: system data. Is structured into three logical components that interact with recognise that people make mistakes.
testing: Testing with customer data to check that the system meets the ⏵Specification: Project proposal: Introduction, Target users and each other.The Model component: manages the system data and associated ⏵User familiarity: The interface should use terms and concepts which are
customer's needs. environments, Key features, Actors. Software development plan: Purpose, operations on that data. The View component: defines and manages how the drawn from the experience of the people who will make most use of the
⏵Evolution: changing the system in response to changing customer needs. Scope, Overview of the project, Project Organization (Roles and data is presented to the user. The Controller component: manages user system.
As requirements change through changing business circumstances, the Responsibilities), Project Management Plan Vision document: Stakeholder interaction (e.g., key presses, mouse clicks, etc.) and passes these interactions ⏵Consistency: The interface should be consistent in that, wherever possible,
software that supports the business must also evolve and change. and User Descriptions, Product Overview, Functional Requirements, Non- to the View and the Model. comparable operations should be activated in the same way.
Propose a plan for each activity to achieve high efficiency Change functional Requirements. Use-case Specification, Use-case Diagram ⏵Use when: There are multiple ways to view and interact with data. The ⏵Minimal surprise: Users should never be surprised by the behavior of a
anticipation: anticipate possible changes before significant rework is ⏵Design & Implementation: Software Architecture Document: future requirements for interaction and presentation of data are unknown. system.
required Change tolerance: The process is designed so that changes can be Architectural Goals and Constraints, Use-Case Model, Logical View,
⏵Recoverability: The interface should include mechanisms to allow users to ▼ Software testing: Concerned with exercising and observing product ⏵ Scrum is an agile method that focuses on managing iterative development
recover from errors. behavior (dynamic verification). The system is executed with test data and its rather than specific agile practices.
⏵User guidance: The interface should provide meaningful feedback when operational behavior is observed. ⏵ There are three phases in Scrum: The initial phase; A series of sprint
errors occur and provide context-sensitive user help facilities. ▼ Inspections and testing: Both are complementary and not opposing cycles; The project closure phase.
verification techniques. Both should be used during the V & V process.
⏵User diversity: The interface should provide appropriate interaction ▼Agile manifesto
Inspections can check conformance with a specification but not conformance
facilities for different types of system users. ⏵ Individuals and interactions over processes and tools
with the customer's real requirements. Inspections cannot check non-
SOFTWARE TESTING
functional characteristics such as performance, usability, etc. ⏵ Working software over comprehensive documentation
▼ Software testing is the process showing that a program does what it is ⏵ Customer collaboration over contract negotiation
∎ 2 TESTING STRATEGIES (PARTITION TESTING AND
intended to do and discovering program defects before it is put into use.
GUIDELINE-BASED TESTING) ⏵ Responding to change over following a plan
▼ The purpose of software testing is: To demonstrate to the developer and
▼ Partition testing: Identify groups of inputs that have common ▼Agile method applicability
the customer that the software meets its requirements. (Validation testing). To
discover situations in which the behavior of the software is incorrect,
characteristics and should be processed in the same way. Should choose tests ⏵ Product development: where a software company is developing a small or
from within each of these groups. Input data and output results often fall into medium-sized product for sale.
undesirable or does not conform to its specification. (Defect testing)
different classes where all members of a class are related. Each of these ⏵ Custom system development within an organization: where there is a clear
▼ The stages in the software testing process:
classes is an equivalence partition or domain where the program behaves in commitment from the customer to become involved in the development
⏵Development testing: The system is tested during development to an equivalent way for each class member. Test cases should be chosen from
discover bugs and defects. Includes all testing activities that are carried out process and where there are not a lot of external rules and regulations that
each partition. affect the software.
by the system development team. Steps: ▼ Guideline-based testing: Use testing guidelines to choose test cases.
⬗ Unit testing (Defect testing): Individual program units (Individual ⏵ Because of their focus on small, tightly-integrated teams, there are
These guidelines reflect previous experience of the kinds of errors that problems in scaling agile methods to large systems.
functions or methods, object classes, composite components) are tested. programmers often make when developing components. General testing
Should focus on testing the functionality of objects or methods. ▼Extreme programming (XP)
guidelines: Choose inputs that force the system to generate all error
⬗ Component testing (Defect testing): Several individual units are integrated ⏵ A very influential agile method, developed in the late 1990s, that
messages; Design inputs that cause input buffers to overflow; Repeat the
to create composite components. Should focus on testing component introduced a range of agile development techniques.
same input or series of inputs numerous times; Force invalid outputs to be
interfaces that behave according to its specification. generated; Force computation results to be too large or too small. ⏵ XP takes an ‘extreme’ approach to iterative development.
⬗ System testing (Defect testing): Some or all of the components in a system AGILE DEVELOPMENT ⏵ New versions may be built several times per day;
are integrated and the system is tested as a whole. Should focus on testing ▼Distinguish between traditional software development process ⏵ Increments are delivered to customers every 2 weeks;
component interactions. Checks that components are compatible, interact (Waterfall), agile software development process (Scrum). ⏵ All tests must be run for every build and the build is only accepted if tests
correctly and transfer the right data at the right time across their interfaces. ⏵ Plan-driven processes are processes where all of the process activities are run successfully
⏵Release testing (Validation testing): (a form of system testing) a separate planned in advance and progress is measured against this plan. ▼Key practices: User stories for specification; Refactoring; Test-first
testing team tests a complete version of the system before it is released to ⏵ In agile processes, planning is incremental and it is easier to change the development; Pair programming
users. The objective of release testing is to check that the system meets its process to reflect changing customer requirements. ▼Problems with test-first development
requirements and is good enough for external use. Is the process of testing a ⏵ In practice, most practical processes include elements of both plan-driven ⏵ It is difficult to contract with clear terms that are used in large companies.
particular release of a system that is intended for use outside of the and agile approaches. ⏵ Agile methods are most appropriate for new software development rather
development team. Main goal: convince the supplier of the system that it is ⏵ There are no right or wrong software processes. than software maintenance. Yet the majority of software costs in large
good enough for use. Is usually a black-box testing process where tests are ▼Distinguish between plan-driven and agile development. companies come from maintaining their existing software systems.
only derived from the system specification. ⏵ Agile methods are designed for small co-located teams yet much software
⏵ Plan-driven development
⬗ Performance testing: Part of release testing may involve testing the development now involves worldwide distributed teams.
⬗ A plan-driven approach to software engineering is based around separate
emergent properties of a system, such as performance and reliability. Tests ▼Problems of Agile maintenance
development stages with the outputs to be produced at each of these stages
should reflect the profile of use of the system. Performance tests usually ⏵ Lack of product documentation
planned in advance.
involve planning a series of tests where the load is steadily increased until the
⬗ Not necessarily waterfall model – plan-driven, incremental development is ⏵ Keeping customers involved in the development process
system performance becomes unacceptable.
possible ⏵ Maintaining the continuity of the development team
⏵User testing: users or potential users of a system test the system in their
own environment. Users or customers provide input and advice on system ⬗ Iteration occurs within activities. ▼Scaling up vs scaling out
testing. Is essential, even when comprehensive system and release testing ⏵ Agile development ⏵ is concerned with using agile methods for developing large software
have been carried out. ⬗ Specification, design, implementation and testing are inter-leaved and the systems that cannot be developed by a small team.
⬗ Alpha testing: Users of the software work with the development team to outputs from the development process are decided through a process of ⏵ is concerned with how agile methods can be introduced across a large
test the software at the developer's site. negotiation during the software development process. organization with many years of software development experience.
⬗ Beta testing: A release of the software is made available to users to allow
them to experiment and to raise problems that they discover with the system
developers.
⬗ Acceptance testing: Customers test a system to decide whether or not it is
ready to be accepted from the system developers and deployed in the
customer environment. Primarily for custom systems.
∎ V&V:
▼ Verification: Check the software being developed meets its specification.
It is concerned with whether the software is built correctly.
▼ Validation: Check the software delivers the functionality expected by the
people paying for the software.It is concerned with whether the software is
useful and meets the users' expectations.
▼ Performing verification and validation throughout the software
development process helps to ensure that the software system is of high
quality, meets the customer’s needs, and is delivered on time and within
budget. It also helps to reduce the cost of fixing defects later in the ▼List and describe all of the principles of agile methods.
development process. Customer involvement: Customers should be closely involved throughout the
development process. Their role is provide and prioritize new system
requirements and to evaluate the iterations of the system
⏵ Embrace change: The software is developed in increments with the
customer specifying the requirements to be included in each increment.
⏵ Incremental delivery: The skills of the development team should be
recognized and exploited. Team members should be left to develop their own
ways of working without prescriptive processes.
⏵ Maintain simplicity: Expect the system requirements to change and so
design the system to accommodate these changes.
⏵ People not process: Focus on simplicity in both the software being
∎ TEST-DRIVEN DEVELOPMENT: developed and in the development process. Wherever possible, actively work
▼ An approach to program development in which you interleave testing and to eliminate complexity from the system.
code development. Tests are written before code and 'passing' the tests is the ▼Why was the agile software development method born to replace
critical driver of development. You develop code incrementally, along with a traditional development methods?
test for that increment. Part of agile methods, such as Extreme Programming.
⏵ The aim of agile methods is to reduce overheads in the software process
(It can also be used in plan-driven development processes.)
(e.g. by limiting documentation) and to be able to respond quickly to
∎ TESTING (dynamic verification)& INSPECTION (static verification):
changing requirements without excessive rework.
▼ Software inspections: Concerned with analysis of the static system
▼What is Scrum and its three phases?
representation to discover problems (static verification). May be
supplemented by tool-based document and code analysis.