Software Development Processes Flashcards
software engineering
Engineering discipline that is concerned with all aspects of software production from the early stages of system specification through to maintaining the system after it has gone into use
requirements engineering
system specification
Software Development Processes
Set of related activities that lead to the production of a software product
main development activities
- specification → RE
- design & implementation
- validation
- evolution
software product
generic software systems sold to a variety of users
software engineering emerged as a discipline in the
1970s
Software projects
“one-off” systems, with the software system based on a set of software requirements
involve an external client or customer who decides on the functionality of the system and enters into a legal contract with the software development company
The customer’s problem and current processes are used as a basis for creating the software requirements, which specify the software to be implemented
customer
reqs
software
customer: generates a problem
reqs: implemented by developer
software: helps the customer with the problem
Software products
no external customer who creates requirements that define what the software must do
The software developer decides on the features of the product, when new releases are to be made available, the platforms on which the software will be implemented, and so on
opportunity
features
software
developer:
has an opportunity -> inspires features -> implements them -> realises the opportunity
Project vs Product based SE
- Product companies can decide when to change their product or take their product off the market. Custom software developed in a software project usually has a long lifetime and has to be supported throughout that lifetime.
- For most products, getting the product to customers quickly is critical. Excellent products often fail because an inferior product reaches the market first and customers buy that product. In practice, buyers are reluctant to change products after they have invested time and money in their initial choice.
Product vision
a simple and succinct statement that defines the essence of the product that is being developed
The product vision should answer three fundamental questions:
- What is the product that you propose to develop? What
makes this product different from competing products? - Who are the target users and customers for the product?
- Why should customers buy this product?
product vision qs
- FOR (target customer)
- WHO (statement of the need or opportunity)
- The (PRODUCT NAME) is a product (product category)
- THAT (key benefit, compelling reason to buy)
- UNLIKE (primary competitive alternative)
- OUR PRODUCT (statement of primary differentiation)
Software product management
a business activity focusing on the software products that are developed and sold by the business
Product managers (PMs)
take overall responsibility for the product and are involved in planning, development, and marketing
Key components of Software product management
- Product vision management
- Product roadmap development
- User story and scenario development
- Product backlog management
- Acceptance testing
- Customer testing
- User interface design
Agile methods are incremental development processes with
- frequent releases of the product
- continuous interaction between dev. team and customer
- reduced product documentation
- continuous and systematic assessment of produced value and risks
Agile in practice
- you make a list of features/reqs
- you estimate
- you set priorities
- you start executing
- you update the plan @run-time
Scrum
A framework for agile project organizations with designated individuals, who act as an interface between the development team and the organization
Scrum roles
product owner
scrum master
scrum team
stakeholder
product owner
- identifies product features and attributes
- reviews the work and ensures that the development team focuses only on the
product, rather than on technically appealing tasks
scrum master
- guides the team in effective use of scrum
- Not a conventional project manager, rather a coach having authority
on how scrum is used in the team
scrum team
self organizing team responsible for developing the product
stakeholder
- customer/end user
- in general, anyone directly or indirectly impacted by the product
Scrum life cycle
Time boxed sprints
- Period of 2-4 weeks
- Activities:
- Planning
- Execution
- Review
- Benefits:
- Demonstrable Progress
- Limited rework
- Improved planning
- Sprints are not extended for unfinished items
Self organising teams
- 5–8 people with no project manager
- Diverse Effective and informal communication
- Decisions are made by mutual consensus.
- Involvement of developers with management and customers is limited
- Coping with team changes is easy
- Communication may be hurdled by:
- All team members not working at same physical place
- Everyone not being able to attend morning meetings
- External interactions
- Team focused (Scrum Master)
- Product focused (Product Owner)
Kanban
Requirement
- A need perceived by a stakeholder.
- A capability or property that a system shall have.
- A documented representation of a need, capability or property.
Requirements Specification
A systematically represented collection of requirements, typically for a system or component.
“Requirement specifications” in agile projects
- Agile projects frequently do not produce a comprehensive requirements specification
- Instead they express requirements in:
- user stories, issues, storyboards, acceptance criteria associated with user stories, etc.
- a vision document
- implicit shared understanding among the people involved
Requirements Engineering: the classic notion
The application of a systematic, quantifiable approach to the specification and management of requirements; that is the application of engineering to requirements.
- Metaphor: upfront engineering
- Goal: complete, unambiguous requirements prior to design
- Smells: paper, process
- Reality check: Does this always work?
Requirements Engineering [Customer oriented]
Understanding and documenting the customers’ desires and needs.
- Metaphor: Customer satisfaction
- Goal: Understand the customer
-
Reality check:
1.- Why not just code what the customer desires and needs?
2.- Who is “the customer”?
Requirements Engineering [Risk-oriented]
Specifying and managing requirements to minimize the risk of delivering a system that does not meet the stakeholders’ desires and needs.
- Metaphor: Balancing effort and value
- Goal: Mitigate risk
A synoptic definition of RE
- A systematic approach for the specification and management of requirements with the following goals:
- (1) Knowing the relevant requirements, achieving a consensus among the stakeholders about these requirements, documenting them according to given standards, and managing them systematically,
- (2) Understanding and documenting the stakeholders’ desires and needs
- (3) Specifying and managing requirements to minimize the risk of delivering a system that does not meet the stakeholders’ desires and needs.
Why do RE?
-
Lower cost
- Reduce error cost
- Reduce rework cost
-
Manage risk
- Meet stakeholders’ desires and needs
- Reliable estimates for deadlines and cost
Stakeholder
A person or organisation that has a (direct or indirect) influence on the system’s requirements
Types of Requirements
a function
a behaviour
a project requirement
a legal constraint
a performance attribute
a quality attribute
a function
The turnstile control software shall count the number of ‘unlock for a single turn’ commands that it issues to the controlled turnstile
a behaviour
The operator shall be able to run the system in three modes:
normal (turnstile unlocked for one turn when a valid card is
sensed), locked (all turnstiles locked), and open (all turnstiles unlocked)
a project requirement
The system shall be deployed at most five months after signing the contract.
a legal constraint
The system must comply with the privacy law of the country where the resort is located.
a performance attribute
The reaction time from sensing a valid card to issuing an
‘unlock for a single turn’ command must be shorter than 0.5 s
a quality attribbute
The system shall be highly available
constraint or
non-functional requirement
classification according to concerns
project <-> process
quality req-attribute : performance + specific quality
functional requirement
Was this requirement stated because we need to specify some of the system’s behaviour, data, input, or reaction to input stimuli - regardless of the way this is done?
performance requirement
Was this requirement stated because we need to specify restrictions about timing, processing or reaction speed, data volume or throughput?
requirements in order of application
functional
perfromance
specific quality
constraint
specific quality
Was this requirement stated because we need to specify a specific quality that the system or a component shall have?
constraint
Was this requirement stated because we need to specify any other restriction about what the system shall do, how it shall do it, or any prescribed solution or solution element?
functional reqs
prescribe what services the software-to-be should provide
non-functional reqs
constrain how services should be provided
