Software Engineering Proficiency Exam
2017-2018.1
Software Processes Course Summary
J. Munch et al. (2012). Software Process Definition and Management. Springer Verlag Berlin Heidelberg.
- Syllabus Content
- Introduction
- Prescriptive Process Models
- Descriptive Process Models
- Process Modeling Notation and Tools
- Process Improvement and Simulation
- Introduction
1 Software Project Challenges
Product quality poor, Deadlines missed, Budget,Overhead, New employees.
2 Information Needs
- Which activities are performed in which sequence?
- Which are the inputs and outputs of these activities?
- Who is involved in a specific activity?
- How long does it take to complete an activity?
- Are specific people bottlenecks?
- How do the activities contribute to higher-level goals?
- …
- How can we gather the required information?
We need a precise and concise model of the process that holds the required information
3 Working in a Team
- Sharing of tasks among specialists
- Parallel working
- Relations between tasks
- Dead ends, contrary viewpoints between the members of the team
- Team leadership
- Synchronization (e.g., coping with late requirements)
- Process requirements, not just product requirements
Coping with these difficulties requires a description of what process is being followed!
4 Process
- Definitions
Process: “A set of partially ordered steps intended to reach a goal.”
Process Step (synonym: elementary process) := An atomic process, which does not allow further structuring in the form of sub-processes.
Process Enactment := The performance of process steps undertaken to reach a given goal. The performer (i.e., ‘agent’) can be a human or a machine.
In case of a machine, the term ‘process execution’ is usually used
Process Definition := A description of a process that is executable Process scripts and process programs are specializations of process definitions
Process Script := A description of a process that is suitable for interpretation by humans
A process script should be tailored to the needs of the process performer.
Process Program := A description of a process that can be interpreted by machines
Process Schema (synonym: process metamodel, process architecture):= a conceptual framework for the consistent description of process models and their relations. It describes: A process schema describes: building blocks that form a process model, and constraints on their composition Only few process management tools are flexible enough to cope with multiple process schemata or are able to import individual process schema. Often, a process schema is created ad hoc together with the process model; this often implies description failures (e.g., phases are refined by processes)
Process Performer (or Agent) := Person or machine that enacts/executes the process in order to reach the process goal(s). Humans interpret process scripts, machines interpret process programs
Process Owner := Human or organizational entity that sets the goals of a process and is responsible for its achievement. A process owner provides resources for the enactment/execution of the process, but he/she is not responsible for providing process definitions
Process Engineer := Person who has to fulfill one or several goals of process modeling (e.g., process definition for guiding developers). To that end, a process engineer uses process models, which he defines, extends, improves, and manages. The process engineer should pay attention to the accuracy of the model, i.e., the correspondence between the real world process enactment/execution and the process model
Role := A set of processes belonging together that are assigned to one or several agents. A role combines the functional responsibility for the enactment of a process
- How to define a process?
-Identification of products and their refinements
-Identification of processes and their refinements
-Definition of product flows
-Definition of control flow
-Assignment of techniques / methods / tools
-Generation of process documentation
5 Software Process Models and the Context
- The characteristics of the environment, the context, determines which process models are the most appropriate for the given situation
- Context factors: Team experience, Application domain, Available budget, Non-functional quality requirements for the system (Reliability, Accuracy, Security, Cost)
Process models need to be tailored for the context and improvement needs to be context-specific
6Selected Benefits of Process Models
- Better transparency of software development activities
- Reduces complexity of large development efforts
- Process models are prerequisites for process assessment
- Process measurement & improvement requires process models
- Prerequisite for reaching predictability (e.g., with respect to completion date, quality); only achievable with explicit models!
7Elements of Process Models
- Identifiable activity or a group of activities
- Product flow (input and output products for activities)
- Control flow between processes (enactment or execution sequence)
- Refinement (hierarchy of processes)
- Relationships to techniques, methods, tools
- Relationships to roles
8Software Process
Software (Development) Process := goal-oriented activity (such as the creation of a product or any other task) in the context of engineering-style software development
Product (or Artifact) := Each artifact that is consumed or produced in the context of engineering-style software development. Products can be refined by other products
Product Flow := Relationships between products and processes that describe the access mode to the products: produce (write/read), consume (read), modify (read/write)
(Software) Product Model := Description of (software) product or a class of (software) products
Usually, software product models consist of a description of the information units of a software product (e.g., functional requirements, non-functional requirements, design decisions) and a structure for arranging the information units (e.g., a table of contents for a requirements document)
- Elements of Process Models (Identifiable activity or a group of activities, Product flow (input and output products for activities), Control flow between processes (enactment or execution sequence), Refinement (hierarchy of processes), Relationships to techniques, methods, tools, Relationships to roles)
- Usually transforms one or more input products by consuming further products (e.g., coding guidelines) into one or more output products
- Can be performed by humans (“enactment“) or machines (“execution“) or both together
- As a refinement, processes can have a set of sub-processes, each of which can also be refined
- Can be part of a system development process
- Can be refined
9Project and Phase
Project := unique endeavor, which is limited by a start date and an end date and should achieve a (set of) goal(s)
Project Phase (short: Phase) := a collection of logically separated project activities, usually culminating in the completion of a major deliverable or the achievement of a major milestone
Project Plan := a specification of the necessary resources for the execution of a process definition,
the relations between these resources and processes, the produced products including the product flows, and restrictions of any type concerning the execution of the process
- Phases are mainly completed sequentially, but can overlap in some project situations
- Phases can be subdivided into sub-phases
- Unlike a process, a phase is always defined by a start and an end. If this period is finished, the phase is finished
- Processes can be activated multiple times
- Prescriptive Process Models
Prescriptive process models advocate an orderly approach to software engineering
1 Families of Software development lifecycle models
- Incremental Models
1 Waterfall Model: for Small projects, and when structure of the problem permits incremental development
2 Incremental for large projects
The Rapid Application Development Model RADfor small projects
- Evolutionary ModelsFor large projects
1 Prototype
2 Spiral
3 Concurrent
Still Other Process Models
- Descriptive Processes
A descriptive process is an adaptation of Prescriptive process to a specific context and needs
- State objectives and scope
■ Goal: Determine the goal(s) of the process modeling and the organizational context:
■Activities:
-Define what the process model will be used for
-Identify the intended users of the model
-Get to know what the intended users expect from the process model and explicitly state their needs
-Identify the granularity of the model
-Determine scope, characteristics, and organizational context
■Input: -
■Output: Process modeling goal
- Select or develop a process modeling schema
■Goal: Schema that identifies and structures the kinds of information to be captured and their relationships
■Activities:
■Identify the concepts to be described using the process modeling goals of step 1
■Select or develop a schema that supports modeling of the identified concepts
■Input: Process modeling goal
■Output: Process modeling schema
- Select (a set of) process modeling formalisms
■Goal: Select a process modeling language or notation
■Activities:
-Select a language or notation that supports the aspects defined in the schema
-If not all aspects are covered by a single language: add other languages or notations until all aspects of the schema can be modeled
-Keep in mind the possible training effort for learning a new complex language!
■Input: Process modeling schema
■Output: (Set of) process modeling languages and/or notations
- Select or tailor tools
■Goal: Select or tailor tools that support modeling using the previously defined language(s)
■Activities:
-Find tools that support modeling using the defined modeling languages
-The tools do not necessarily have to be process modeling tools, they can also be simple drawing tools
-If necessary, tailor the tools to the specific needs of the languages
-For the selected tools, identify the functionality that should be used for modeling
■Input: Process modeling languages or notations
■Output: Set of modeling tools
- Elicitation(see Software Requirements Engineering Course)
■Goal: Acquire all information needed to describe the software process
■Activities:
-Identify all entities (agents, activities, products,…), their relationships, and their properties (e.g., start conditions of activities)
-Get information through:
- Interviews (used most often)
- Observation
- Analysis of protocols
- Analysis of process documents
- Analysis of products
-Make sure the process agents do not feel judged or evaluated by the person eliciting! If they do, they will describe an ideal process, not the actual process!
■Input: Real process to be modeled
■Output: All needed information about the process (interview protocols, observation protocols, process documents,…)
- Create the process model
■Goal: Create a process model in the defined language or notation that represents the analyzed process
■Activities:
-Start by modeling the products
-Model activities and product flow
-Assign agents and responsibilities to activities
-Model behavior (start, end of activities)
-Review the process model together with process participants
-If necessary, go back to the elicitation step to get needed information
■Input:
-Process modeling languages or notations (Step 3)
-Process modeling tools (Step 4)
-Elicited information about the process (Step 5)
■Output: process model representing the observed process
- Analyze the process model
■Goal: Detect inconsistencies in the model to check whether the model correctly describes the real process and to identify improvement possibilities
■Activities:
-Static analysis
- Completeness (does the model contain all information needed to reach the modeling goal?)
- Correctness (is the model free of contradictory information?)
- Structural consistency (e.g., are all products used by a refined activity used by at least one of its child activities?)
-Dynamic analysis (analysis of behavior during execution)
- Identification of deadlocks, ambiguous situations,…
- Identification of process weaknesses (critical paths, cost overruns,…)
- If an identified inconsistency is due to a misunderstanding of the process, refine the process model
■Input: process model; process modeling goal
■Output: refined process model; suggestions for improvement
- Analyze the process model
■Goal: Use the process model to track or analyze process performances, depending on the process modeling goal
■Activities:
-Track the performance of the process by registering starts or endings of activities or by asking developers about their current activities
-If necessary, fine-tune the process model with the results of the tracking
-Qualitative analysis: weaknesses of the process
-Quantitative analysis: correlation between process attributes
■Input: process modeling goal; process model
■Output: depending on goalRefined process model, improvement options,…
- Process Modeling Notation and Tools
Several Modelling languages and tools support Process Modeling (UML, Visio, MVP-L, …). See Modelling Course Notes. The following Process modeling issues are supported:
Architectural model: Use Case model (functional), Object model, …
Behavioural models: Structured and OO Methodologies
Activity / States Model AD/ SD (UML tools)
Process Models: Structured and OO Methodologies
- Narrative model Text Processing tool
- Pseudo code model Process Programming Language (PDL) tools
- Equations Model Algebraic Specification/ Z language tools
- Diagrams/ Chart model DFD/Flow Chart tools
Communication Models: Structured and OO Methodologies
Sequence/ Collaboration Models SeqD/ColD (UML tools)
- Process Improvement and Simulation
1 Methods of Improvement
■Can for instance be classified as
- model-based if process improvement is based on existing reference models or
There are many kinds of standardized reference models available such as Capability Maturity Model Integration (CMMI) and ISO/IEC 15504 (SPICE)
- continuous if improvement is more evolutionary and focused on a set of issues identified in the organization.
-Continuous improvement approaches are often problem-based which means that a specific issue is first identified and analyzed after which a solution can be proposed, implemented in a proper fashion and finally the outcome can be reviewed
-On the bright side, this way improvement is focused to the actual problems faced by the organization and as such quite specific to the organizations; with proper measurement in place, impact of improvement initiatives can be seen without much latency
-Focused improvement activities might not always be a blessing for the organization in that sense that improvement is somewhat local
■Continuous Improvement
1 Plan-Do-Check-Act (PDCA)
-Plan-Do-Check-Act (PDCA) is a continuous improvement approach that can be used to solve specific problems
-Plan - Perform a problem or potential analysis
-Do - Implement and perform improvement actions
-Check - Analyze the success of the improvement actions
-Act - Analyze the differences between the actual and the expected results, determine their causes, and define appropriate means to achieve the expected results
2 Software Process Versioning
- Software objects are results of development or maintenance activity.
- Relationships connect software objects
-Composition
-Dependency
- Representations:
- Modules with dependencies
- File system structure
- Tree structure with typed objects and relationships
- Dependency graph
- Example
- One-Level Version Graphs (Each version connected by one single type of relationship called “successor”)
- Multi-Level Version Graphs
Two-level organizations
Graph is composed of branches each with a sequence of revisions
At least two relationships: Successor (within a branch), Offspring (between branches)
- AND/OR graphs
3. Specific Software Process
From the software versions space, a specific coherent software process may be generated according to its specific needs.
SE BSc Proficiency Exam Software Processes Summary 2016-2017.1 1/13