- software process - a roadmap to building high quality software
products
- software processes are adapted to meet the needs of software engineers and managers
- a software process provides a framework for managing activities
- different types of projects require different software processes
- the software engineer's work products: programs, documentation, data - produced from activities defined by the software process.
- best indicators of how well a software process has worked - quality,
timeliness, and long-term viability of the resulting software product
- establishment of sound engineering principles, applied to obtain reliable and efficient software in an economical manner
- application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software
- encompasses a process, management techniques, technical methods,
and the use of tools
- Communication - customer collaboration and requirement gathering
- Planning - establishes engineering work plan, describes technical risks, lists resource requirements, work products produced, defines work schedule
- Modeling - creation of models to help developers and customers understand the requirements and software design
- Construction - code generation and testing
- Deployment - software delivered for customer evaluation and feedback
- the framework activities will always be applied on every project ... BUT
- the tasks (and degree of rigor) for each activity will vary based on:
- the type of project
- characteristics of the project
- common sense judgment
- concurrence of the project team
- software project tracking and control
- allows team to assess progress and take corrective action to maintain schedule
- risk management
- assess risks that may affect project outcomes or quality
- software quality assurance
- activities required to maintain software quality
- formal technical reviews
- assess engineering work products to uncover and remove errors before they propagate to next activity
- measurement
- define and collect process, project, and product measures to assist the software team in delivering software meeting customer needs
- software configuration management
- manage effects of change
- reusability management
- defines criteria for work product reuse and establish mechanisms to achieve component reuse
- work product preparation and production
- activities to create models, documents, logs, forms, lists, etc.
- activities to create models, documents, logs, forms, lists, etc.
- overall flow and level of interdependencies among tasks
- degree to which work tasks are defined within each framework activity
- degree to which work products are identified and required
- manner in which quality assurance activities are applied
- manner in which project tracking and control activities are applied
- overall degree of detail and rigor of process description
- degree to which stakeholders are involved in the project
- level of autonomy given to project team
- degree to which team organization and roles are prescribed
- Level 0: Incomplete
- process is not performed or does not achieve all goals defined for
- Level 1: Performed
- work tasks required to produce required work products are being conducted
- Level 2: Managed
- people doing work have access to adequate resources to get job done
- stakeholders are actively involved
- work tasks and products are monitored, reviewed, and evaluated for conformance to process description
- Level 3: Defined
- management and engineering processes documented, standardized, and integrated into organization-wide software process
- Level 4: Quantitatively Managed
- software process and products are quantitatively understood and controlled using detailed measures
- Level 5: Optimizing
- continuous process improvement is enabled by quantitative feedback
from the process and testing innovative ideas
- continuous process improvement is enabled by quantitative feedback
from the process and testing innovative ideas
- templates or methods for describing important characteristics of software processes
- software teams can combine process patterns to construct processes that best meet the needs of specific projects
- generic software pattern elements
- meaningful pattern name
- intent (objective of pattern)
- type
- task pattern - defines engineering action or work task
- stage pattern - defines framework activity for the process
- phase pattern - defines sequence or flow of framework activities that occur within process
- initial context - describes conditions that must be present prior to using pattern
- solution - describes how to implement pattern correctly
- resulting context - describes conditions that result when pattern has been implemented successfully
- related patterns - links to patterns directly related to this one
- known uses/examples - instances in which pattern is applicable
- SPICE (ISO/IE15504) standard
- defines a set of requirements for process assessment
- provides a reference model
- SPICE model assessment is a structured evaluation of a process model
- ISO 9001:2000 for Software
- defines requirements for a quality management system that will produce higher quality products and improve customer satisfaction
- stresses the importance for an organization to identify, implement, manage, and continually improve processes
- process effectiveness and efficiency are assessed through internal or external review
- results can be documented and monitored over time
- Framework activities
- Planning (size and resource estimates based on requirements)
- High-level design (external specifications developed for components and component level design is created)
- High-level design review (formal verification methods used to uncover design errors, metrics maintained for important tasks)
- Development (component level design refined, code is generated, reviewed, compiled, and tested, metric maintained for important tasks and work results)
- Postmortem (effectiveness of processes is determined using measures and metrics collected, results of analysis should provide guidance for modifying the process to improve its effectiveness)
- Levels
- Level PSP 0 (personal measurement) - original process used
- Level PSP 1 (personal planning) - original process is modified slightly by introducing a moderate number of PSP tasks to small project; resource, size, and defect estimates are made, results are measured and defect/effort measurements are logged and analyzed
- Level PSP 2 (personal quality) - original process is modified significantly by introducing a moderate number of PSP tasks to small project; resource, size, and defect estimates are made, results are measured and defect/effort measurements are logged and analyzed
- Level PSP 3 (cyclic process) - full scale PSP process implemented
and applied to sequence of small projects
- Objectives
- Build self-directed teams that plan and track their work, establish goals, and own their processes and plans
- Show managers how to coach and motivate their teams and maintain peak performance
- Accelerate software process improvement by making CCM Level 5 behavior normal and expected
- Provide improvement guidance to high-maturity organizations
- Facilitate university teaching of industrial team skills
- Scripts for Project Activities
- Project launch
- Design
- Implementation
- Integration and system testing
- Postmortem
- used to adapt process models to be used by software project team
- allow organizations to build automated models of common process framework, task sets, and umbrella activities
- automated models can be used to determine workflow and examine alternative process structures
- tools can be used to allocate, monitor, and control all software engineering tasks defined as part of the process model
- tools help, but they are not a panacea (a remedy for all ills or difficulties)