Waterfall software process
Requirements: product requirements document Design: software architecture Implementation: software Verification: Maintenance:
Accidental complexity
Relates to problems which engineers create and can fix
Ex) the details of writing and optimizing code
Essential complexity
Is caused by the problem to be solved and relate to the complexity of context and stakeholders involved
Problem of requirements
- difficult to communicate clearly
- difficult to document
- difficult to negotiate
- difficult to manage (change)
Success Factors in 1995
- User involvement
- Executive management support
- Clear statement of requirements
- Proper planning
- Clear vision and objectives
Success factors 2015
- Execute sponsorship
- User Involvement
- Agile process
- Modest execution
- Clear business objectives
Importance of software process
Project success
Financial
Safety
Mitigate project risks
- continuous access to stakeholders
- incremental and iterative software development
- having cycles instead of steps
Waterfall vs agile
- waterfall does each step then done, not used anymore
- agile has a cycle of testing and coding (working with stockholder) better method (ex scrum and spring planning in scrum)
Model, view, controller
- segment our ideals from the model (sep how we interact with it to how we view it)
- benefits: to make changes you know where to go and don’t have to change everything, easier to test components
- downsides: disperse function into three parts and makes it hard to find code, takes over code and takes away flexibility
Module cohesion
The extent to which software entities pertaining to the same functionality are contained within a single module
Inter-module coupling
The extent of inter-module connections
Architecture quality attributes
Want low coupling and high cohesion
-results in easier maintenance of code, higher modifiability, and localization of changes
Categories of requirements
- Functional requirements: what the software should do
- Quality requirements: qualifications (speed, reliability, …)
- Constraints: coming from somewhere (programming language, platform)
Role of architecture
- Functional requirements: ability of system to do work it was required
- Quality requirement: satisfied by quality of the system as a whole
Functionality
-the ability of the system to do the work for which was intended
-has the strangest relationship with architecture
Eg) “when user presses the green button something happens”
Quality requirements
Pertain to the functions of a system
Eg) how quickly does the dialog appear (performance)
How often will func fail (availability)
(Usability)
Two categories of QA’s
- ones that describe property of the system at runtime (availability, performance, usability)
- ones that describe some property of development of the system (modifiability, testability)
Problems with QA’s
- Testability: many quality attributes are difficult to test
- Mapping of concern: is a system failure due to a denial-of-service attack an aspect of availability, an aspect of performance, an aspect security or usability
Storyboarding
Powerful validation technique
-always them to see if it looks and flows the way it should
V & V activities through development
- Requirement: rapid prototyping
- Specification: do conform to req and any ambiguity
- Design: design checked for faults
- Implementation: tested and walk through (black-box~ don’t care about implementation white-box ~ do)
- Integration: work in things independent and can be brought together
- Product Testing: look at specs and start to check boundary’s outside spec
- Acceptance Testing: software given to client to test
