Software Engineering Terms Collection 2

Abstract

This note collect all terms occur in SEPP Lecture 6/7/9. It would be helpful to recap what has learnt and what has already been abstracted away.

Pool of atomic terms

plan-driven development process, heavy documentation, formal documentation, iteration, agile development process, individual, interaction, working software, customer collaboration, responding to change, design, implementation, unfinished feature, requirement engineering, requirement specification document, omnipresent, details

software project, long-lived system, software product, developing team, small-medium sized system, several potential customer, speedy delivery, feature

elicitation, interview, survey, facilitated meeting, informal user analysis, informal user discussion

persona, personalisation, name, personal circumstance, stock photograph, job, education, background, technical skill, experience, relevance, shared vision, key system feature

scenario, narrative, context, user, perspective of the user, real users, role, responsibility, high-level scenario, use-case scenario, brief statement, overall objective, activity, current system, identified problem, specific details, reality, team member, user, expert, brainstorming, shared understanding, facilitate communication, design creativity, specification

user story, sequence of interaction, format

trade-off, simplicity, functionality, familiarity, novelty, automation, control, feature creep, action, action verbs, phrases, simple list, input, action, output, description, constraint, comment, user needs, options

output, model, UML, Simulink, graphical model, executable model, written document, record reasons, decision, good design, known requirement, future requirements, implementers, existing technology, reusable components, human angle, situation-dependency, OO design, functional design, OO programmer, functional programmer, design choices, future changes, different levels, subsystems, classes, responsibility, interface, message, order

architecture, fundamental influence, non-functional characteristics, non-functional attribute, component, database, maintainability, resilience effect, fundamental organization, software system, component, relationship, environment, principles, design, evolution, related system, named software unit, coherent set of functionality, collection of services, coherent unit of functionality, module, named set of components

architectural design, product lifetime, software reuse, number of users, software compatibility, planned schedule, team capacity, budget, large-scale components, cross-cutting concerns, major concern, complexity, local data, separation of concerns, related functionality, implement once, stable interface

distribution architecture, client-server architecture, web-based software product, mobile software product, client, load balancer, server, web, database, Model-View-Controller pattern, MVC, multi-tier client server architecture, object-oriented approach, shared database, structured data, concurrent update, business system, local servers, service-oriented architecture, change regularly, scalability, resilience to failure, peer to peer architecture, message bus architecture

technological consideration, database, delivery platform, server, open source platform, development technology

detailed design, design principle, class diagram, cohesion, understandability, maintainability, reliability, coupling, abstraction, encapsulation, information hiding, separation of interface, separation of implementation, public interface, decomposition, modularisation

Key linkage between atomic terms

term ‘feature’ aims to distinguish from ‘requirement’ coming from a customer (in software project), but similar in meaning.
personas will overlap, Sommerville advises using max 5 personas.
software product are recommended to use high-level scenario, different to use case scenario.
team member works individually on a subset of scenarios.
get user involved in the development.
Sommerville recommends using 3-4 scenarios/persona.
requirement need to be: independent, coherent, relevant.
user stories may immediately suggest requirements.
start by using product, but then think creatively about other/additional more efficient and interesting options.
design is the process of deciding how software will meet the requirements. Usually exclude detailed coding level.
maintainability vs performance
security vs usability
availability vs time to market and cost
major concern of designing architecture is complexity due to the number of components and their relationship, the latter increasing exponentially.
multi-tier client-server architecture is a client-server system with a shared database.
technologies need to be decided, since architectural design, as changing them later is difficult and expensive.