COMP 354

Adapted from Stuart Thiel's lecture, 2018 Summer.

People and Process

Development Phases & Testing and TDD

Development Phases

Testing and TDD

Who test?

  • Outside testers are objective
  • Inside testers can be biased, but know their software
  • Within a team, worth having developers and colleagues test code

What is a good test?

  • Catches most bugs with least effort
  • One from each type of test class
  • What might a test class be, given this?
  • Testing randomly?
  • Testing exhaustively?

Why types of tests?

  • Different types of tests match up with different artifacts
  • Different types of tests reveal/confirm different types of issues/features

What types of tests?

  • Unit Testing (P474)

    • Step-by-step with coding
    • In OOD, a unit is usually a class
    • In functional development, it can be a method/function being tested
    • Makes use of stubs and drivers
    • Should be automated

  • Integration Testing

    • Test the quality of the documentation and communication
    • Finding side effects
    • ncremental integration is best
    • Top-down or Bottom-up
      • Top-down
        • Verifies major control or decision points early
        • Depth-first: tests integration of critical paths of modules
        • Breadth-first: is good as integration is often tight along a horizontal layer
      • Bottom-up
        * Skips the need for stubs
        * builds (or clusters) are groupings of low-level modules that have been integrated
        * drivers test these integrated clusters
        * as you move up, throw out the drivers and replace with next level to be integrated
    • Regression Testing
      • Find a bug, write a test that catches it.
      • That bug is fixed when regression tests passes
      • That bug should never come back
    • System-level (Validation) Testing
      • Tests user-visible features
      • Tests imitate user interactions with system
    • Acceptance Testing (2.P183)
      • a test of the requirements
      • Leffingwell is focused on Story Acceptance testing, that’s ok
      • Does a user using the system see high level functionality they expect?
      • Does a user using the system see the feature they expect?
      • What about non-functional requirements?
    • Black box Testing
    • White box Testing
    • Other Types of Tests
      • What types of things from the artifacts aren’t tested by the mentioned tests?

Testing strategy

  • Inception and Elaboration may have more focus on unit test, but still have acceptance tests.
  • As you move on, Integration tests and System tests become more relevant
  • As soon as you have bugs, regression tests are relevant

Requirements

What are requirements?

  • "Requirements are capabilities and conditions to which the system–and more broadly, the project–must conform"
  • "Inception is Not the Requirements Phase"
  • Needs drive features, features drive requirements
  • Requirements are best when understood by both developers and customers

What are stories?

  • In Scrum, a Story is a brief statement of intent describing something the system can do for a user
  • Stories are negotiable, and should be small enough to make good estimates on
  • User Stories are what we are mostly concerned with
  • Stories can also include other work items, but those aren’t really related to requirements

What are features?

  • Bridge gap between User needs and Software Solutions (Requirements)
  • Most systems described in 25-50 features
  • Features are Program Backlog items in Scrum
  • You can Acceptance Test features

When we must have requirements?

  • Design and development start while only 10-20% of requirements are established
  • Requirements, even established ones change
  • "on average, 25% of requirements change on software projects"
  • Study on waterfall-esque requirements showed 45% were never used, 19 % were rarely used
  • Iterative approach: have the requirements you need, when you require them.

Use Cases

Definition: What are Actors, Scenarios, and Use Cases?

  • Action: an actor is something with a behaviour. such as a person (identified by a role), computer system, or organization; for example, a cashier.
  • Scenario (use case instance): a scenario is a specific sequence of actions and interactions between actors and the system; also called use case instance
    • Main Success Scenario: is the story of everything going as planned, successfully
    • Alternate Scenario: is a story of an important deviation from the Main Success Scenario
  • Use cases:
    • A use case is a collection of related success and failure scenarios that describe an actor using a system to support a goal.
    • (RUP definition) A use case is a set of use-case instances, where each instance is a sequence of actions a system performs that yields an observable result of value to a particular actor.

Use Case Model

  • A reminder that Use Cases are about text, not UML!
  • Use Case Model is a quick way to show written Use Cases, provides a context diagram
  • RUP considers the UCM a requirements artifact.
  • Use Cases aren't OO. They are not about OO analysis, but OOA/OOD can use Use Cases as input

Why Use Cases (P121)

  • Lack of user involvement is bad, Use Cases helps user to participate.
  • Capturing goal is good
  • Simple systems work best, it will be easier for customer to contribute to their definition and review.

Definition: Are Use Cases Functional Requirements?

  • Use Cases are primarily functional or behavioral requirements that indicate what the system will do.
  • Can describe other requirements as well
  • In many processes, Use Cases are central mechanism to discover and define requirements
  • Use Cases are more than just requirements

Definition: What are Three Kinds of Actors?

  • Primary Actor: Has user goals fulfilled through using the system.
    • Usually a person
    • Can be a system or organization
  • Supporting Actor: Provides a service to the system
    • usually a computer system.
    • Can technically be an organization or a person.
  • stage Actor: Has an interest in the behavior of the use case, but is neither Primary nor Supporting, identify (external) interests to make sure their needs are met.
    • government tax organization making sure your payment processing is legal

Notation: What are Three Common Use Case Formats?

  • brief : Short summary, usually just the Main Success Scenario
  • casual : Maybe a few paragraphs, covering the basics, one paragraph per scenario, including some Alternate Scenarios.
  • fully dressed : All steps and variations written in detail, includes supporting sections, usually in a tabular format.

Structural Design Class & RDD and GRASP Patterns

Structural Design

Structural Design: Class Deagrams and OOD

Object Oriented Design

  • Object Oriented Design [1, p.7]
    • Define Software Objects
    • Identify how they collaborate to meet requirements
  • Domain Model vs. Class Diagram
    • A Domain Model uses the same notation
    • A Domain Model is for Conceptual Classes
    • Larman likes to use "Design Class Diagram" to distinguish from Domain Models
  • Class Diagrams
    • UML notation is very standard
    • Static Object Modeling
    • Attributes, methods and associations
      • All these things in detai

RDD and GRASP Patterns

Responsibility-Driven Design (RDD) [1][2,p276-277]

  • attempts to increase encapsulation by using client-server model
  • Focus on intent of request instead of how a request will be served
  • Focus on behavior of objects

RDD Roles

  • Controller: makes decisions, directs actions of other objects
  • Coordinator: reacts to events, delegates tasks to others
  • Information Holder: knows and provides information
  • Interfacer: transforms information and requests between objects
  • Service Provider: performs work and encapsulates computing services
  • Structurer: maintains relationships and metadata about relationships between other objects

GRASP [2, cover, p.277-279]

  • General Responsibility Assignment Software Patterns(Principles)
  • An aid to design that is rational, explainable.
  • Pattern Names communicate effectively
  • Patterns aren't new, they are established

The Patterns [2, cover]

  • Creator: Assign Responsibility of creating class A to class B if:
    • B "contains" most/all groups/groupings of A
    • B records A
    • B closely uses A
    • B has the initial data for A
  • Information Expert: "Assign a Responsibility to a class that has the information needed to fulfill it."
  • Controller: Can Represent a System or a Use Case (two avors)
    • Represents the overall system (facade controller) or
    • Represents a Use Case (session/use case controller)
    • In your pokemon game?
    • Might be your pokemon game?
    • Might be what handles a player's turn?
    • Both approaches are common
    • Both involve handling high-level flow of the application.
  • Low Coupling(P444): Assign responsibilities so coupling stays low
    • Coupling: How closely one element is connected to another
    • has knowledge of
    • depends on
    • uses/is used by
  • High Cohesion (P461): Assign responsibilities so cohesion stays high
    • Cohesion: How well things that are together belong together
    • "incidental/coincidental cohesion" bad
    • "Functional" good
  • Bad Cohesion
    • Incidental/Coincidental: just stuck together because, utilities/leftovers
    • Logical: logically related ideas/behaviours, even if purpose and application are different
    • Temporal: the things happen at around the same time
  • Moderate Cohesion
    • Procedural: control chains through the various behaviours
    • Sequential: control chains through the various behaviours as outputs from one are inputs to another
    • Communicational2/Informational: the behaviours are applied to the same types of data.
  • Cohesion Functional: all behaviours related to one and only one specific task good
    • Polymorphism (later)
    • Pure Fabrication (later)
    • Indirection (later)
    • Protected Variation (later)

Design Patterns

Design Patterns

What are patterns?

1: 17.6

  • Developers "build up a repertoire of both general principles and idiomatic solutions"

  • When described in terms of a name, a problem and a solution, we call these patterns.

    e.g.

    Pattern NameInformation Expert
    Problem:What is a basic principle by which to assign responsibilities to objects?
    Solution:Assign a responsibility to the class that has the information needed to fufill it.

  • Pattern names let us quickly share a lot of information

  • Patterns are identified, not created. "codify existing tried-and-true-knowledge"

GRASP and GoF

1: 17.6

  • Named patterns in software are attributed to Kent Beck, mid-80s
  • Gang of Four book came out in 1994, became the accepted design guide, describing 23 core Design Patterns.
  • GRASP patterns were popularized by Larman in 2000-2010s
  • The General approach to Pattern-Based design is broad

Which Patterns to Consider?

  • It is worth taking a look at Pattern-Based Design in general

General Pattern-Based Design

2: Chapter 16

  • Most problems you face have already been solved
  • The trick is to find the solution and apply it within your design-space

What is it?

Pattern-based design creates a new application by finding a set of proven solutions to a clearly delineated set of problems. Each problem and its solution is described by a design pattern that has been cataloged and vetted by other software engineers who have encountered the problem and implemented the solution while designing other applications. Each design pattern provides you with a proven approach to one part of the problem to be solved.

Who does it?

A software engineer examines each problem encountered for a new application and then attempts to fi nd a relevant solution by searching one or more patterns repositories.

Why is it important?

Have you ever heard the phrase “reinventing the wheel”? It happens all the time in software development, and it’s a waste of time and energy. By using existing design patterns, you can acquire a proven solution for a specific problem. As each pattern is applied, solutions are integrated and the application to be built moves closer to a complete design.

What are the steps?

The requirements model is examined in order to isolate the hierarchical set of problems to be solved. The problem space is partitioned so that subsets of problems associated with specific software functions and features can be identified. Problems can also be organized by type: architectural, component-level, algorithmic, user interface, and so forth. Once a subset of problems is defined, one or more pattern repositories are searched to determine if an existing design pattern, represented at an appropriate level of abstraction, exists. Patterns that are applicable are adapted to the specific needs of the software to be built. Custom problem solving is applied in situations for which no patterns can be found.

What is the work product?

A design model that depicts the architectural structure, user interface, and component-level detail is developed.

How do I ensure that I’ve done it right?

As each design pattern is translated into some element of the design model, work products are reviewed for clarity, correctness, completeness, and consistency with requirements and with one another.

  • It turns out that while this is effectively true, there’s more effort than is implied
  • Still, developers have built up many pattern repositories to help with all sorts of software design

A General Approach to General Patterns

  • Problems have context, and qualities, which pressman calls "forces"
  • Given a context and the qualities of a problem, the goal is to find the best matching solution.
  • An effective design pattern in the following way:
    • It solves a problem
    • It is a proven concept
    • The solution isn’t obvious
    • It describes a relationship
    • The pattern has a significant human component (minimize human intervention)
  • "Design patterns, if used effectively, will invariably make you a better software designer."

Pattern Types and Standard Groups

  • There are many kinds of patterns
    • Architectural
    • Data
    • Component (or Design)
    • User Interface
    • WebApp
  • GoF broke patterns into groups
    • Creational: focus on creation, composition and representation of objects while hiding how these things are done
    • Structural: focus on how objects are organized and integrated to create something larger
    • Behavioural: focus on the assignment of responsibility between objects and the manner in which they communicate

Approaches to Pattern-Based Software Design

  • Frameworks can facilitate the application of some types of patterns (SOENEA)
    • Note that frameworks are not patterns, as they are "embodied in code"
  • Describing the problem carefully is key in identifying an appropriate pattern
  • Pattern languages and pattern repositories can make communicating and finding patterns easier
  • Look for ways to apply existing design patterns (vs. trying to create something new)
  • Quality considerations are built into good patterns

Pattern-based design in context

Pattern-based design in context

Thinking in Patterns

  • Mental Design Steps:
    1. Keep the big picture in mind
    2. See the patterns in the big picture
    3. Form these patterns into a context for your later design work
    4. Work inwards from this context, looking for pattern at gradually lower levels
    5. Repeat until design is fleshed out
    6. Refine your design by adapting patterns to your specific software
  • A pattern choice at one level, may well affect pattern choices below or laterally
  • Patterns are connected, they are not independant

Design Tasks

  • Pressman suggests following design tasks related to the Mental Design Steps.
  • Determine the domain, and find a related pattern language or pattern repository
  • Search for architectural patterns to apply for that domain in the specific problem
  • In areas where architectural patterns have been defined, focus on subsystem or component-level (GoF design) patterns.
  • Keep cycling through till the broad system is covered for both architectural and design/subsystem level patterns
  • If GUI patterns are identified, review GUI design patterns against known pattern repositories
  • Refine all these patterns carefully to match up with your actual problem context

Common Mistakes

  • People don’t spend enough time fully understanding the problem
  • People choose a wrong pattern, and then stick to it, unable or unwilling to see that it is wrong
  • People apply patterns too literally, not willing to refine appropriately for the specific problem, or just being pedantic about their application.

Architectural Patterns

  • These decisions impose constraints on all lower level design
  • These patterns are the hardest to change once decided on
  • These patterns address the structure of the application and key risk areas
  • On the bright side, the application of these patterns is often well understood for specific domains (e.g. e-commerce site)

Architectural Pattern Domains

  • Access Control: patterns that address restricting access to information or behaviour
  • Concurrency: patterns doing many things at once, most commonly because many users may use the system at once (e.g. Enterprise Applications). This can include task schedulers or other mechanisms to avoid problems that arise from concurrency.
  • Distribution: These patterns apply when an application is not isolated to one system (or process). These patterns address the various problems and standard solutions (e.g. web applications)
  • Persistence: Persistence of data can vary from text files to databases, and architectural patterns cover the retrieval and storage or persisted data, as well as the means to properly integrate it into a running application and back again.

Component-Level Patterns

  • Often focus on a functional element of a system
  • Pressman presents it very similarly to the UI patterns
  • Generally appears to focus on mid-level interactions with the system

UI Design Patterns

  • These describe established solutions to known UI problems
  • Generally deal with layout styles or navigation
  • Often they are effectively widgets with known behaviours to address a problem (calendar date-picker, etc.)
  • While there is no general guidance in Pressman as to what these really are, the listed patterns are good guidance, and finding pattern repos related to these elements is worthwhile (JQuery UI comes to mind).

More GRASP Patterns

GRASP from Memorial University

  • These patterns are closer to the traditional GoF design patterns than the first five we looked at.
  • Keep in mind what you see here for when we consider the GoF patterns. This will give you a robust pattern language to discuss software design with

Polymorphism

  • Problem: Handling alternatives based on type, creating pluggable software components

  • Solution: When related behaviour varies by type, assign responsibility for the behaviour to the types for which the behaviour varies, generally by using polymorphic operations.

  • Implementing the same interface does this, but it can be done just as well with dynamic binding.

  • Overloading methods or the use of the Visitor pattern can extend how this approach can be applied.

    public interface Shape {
    void draw();
    }
    public class Circle implements Shape {
    void draw(){
    // do something
    }
    }
    public class Square implements Shape {
    void draw(){
    // do something
    }
    }
    public void test(Shape shape) {
    shape.draw();
    }

Polymorphism in Sequence Diagrams

  • Show the general call in the main frame
  • Show alternate frames with the outcome for each type of polymorphic call.
  • Web Sequence Diagram it?

Bad Polymorphism Alternatives

  • Switch statements
  • passing around type ids

Pure Fabrication

  • Problem: When you do not want to violate High Cohesion or Low Coupling (or other things), but you do not have a suitable option.
  • Solution: Assign highly cohesive behaviors to an artificial/convenience class.
  • Eliminate a bad design based on other GRASP patterns with a good design that is generally more reusable.

Pure Fabrications Practices

  • Not always important to identify Pure Fabrication
  • It is important to know when to use it to improve design
  • e.g. when explaining why an Information Expert approach was not used, answer that it would have led to high coupling or low cohesion (but not because Pure Fabrication, that’s the solution, not the reason)

Bad Pure Fabrication

  • Sometimes people apply behavioural decomposition such that a Pure Fabrication class wraps a single function, or very few functions. This is bad.
  • Decomposition in that direction may seem natural, but it should be avoided so that representational decomposition can be more valuable... leaving some behaviours in non Pure Fabrication classes as appropriate.
  • This type of overuse is often indicated by Low Cohesion.

Indirection

  • Problem: Need to avoid direct coupling between two or more things, keeping coupling low and reuse potential high
  • Solution: Assign responsibility to an intermediate object that mediates between other components or services, thus removing direct coupling
  • These often lead to Adapters, and generally serve to hide the mess of managing such flexibility.

Protected Variation

  • Problem: variance and instability in one element can perpetuate instability to related elements
  • Solution: Identify points of predicted variation or instability and assign responsibilities to create a stable interface around them (broad use of the term interface).
  • Whereas Indirection was to address coupling for the sake of coupling, this approach targets a more specific problem (though the two can be very related).
  • This is all about data encapsulation and information hiding, core OO design tricks
  • With experience, you can see exactly where to apply this most of the time
  • Still very valuable to understand

References

[1] Craig Larman. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development. Addison Wesley, 3rd edition, 2013.

[2] Roger Pressman. Software Engineering: A Practitioner’s Approach (7th ed.). Pearson, 2010.

Gang of Four Patterns

[1, p.280,435,436]

  • Named after Gamma, Helm, Johnson and Vlissides, who wrote the mid-90s book "Design Patterns"
  • Covered 23 core design patterns, arguably the most popular software design pattern language in use today.
  • "15 are common use and most useful."

Adapter

  • Problem: incompatible interface, similar components with differing interfaces
  • Solution: Convert the original interface into another interface through an intermediate adapter object.
  • Polymorphism from GRASP uses the adapter pattern, the adapter being the common interface.
  • Often a common interface will be made, and adapters implementing that interface will delegate to the varying objects, hiding the differences.
  • e.g.: Pattern-based design in context

Factory

  • GoF pattern is actually "Abstract Factory"
  • Problem: Need to create object with special considerations like complex creation logic, the need to separate concerns and hide variation in the created objects, the need to generally maintain high cohesion.
  • Solution: Create a Pure Fabrication object called a Factory that handles the creation.

Singleton

  • Problem: Exactly one instance of a class is allowed. Other objects need a global and single point of access
  • Solution: Define a static method of the class that returns the singleton
  • Concurrency control is common around Singletons.
  • e.g.: Pattern-based design in context

Why not make it all static?

  • instance-methods allow subclassing, refinement (overloading) of the Singleton class for effective reuse. Static methods aren’t polymorphic, and generally don’t support overwriting in languages where such things are allowed (part of the definition of the class)
  • Remote access methods generally support only instance-methods. (e.g. Java’s RMI)
  • A class is not always needed as a singleton in all applications.

Strategy

  • Problem: Algorithms or policies can or will change, need to be decided at run-time
  • Solution: Define each algorithm/policy/strategy in a separate class with a common interface
  • Often this leads to the instance of the strategy being created by a Factory that is passed enough info to know what to do.
  • Polymorphism and Protected Variation at work!
  • e.g.: Pattern-based design in context

Composite

  • Problem: A number of similar objects need to be treated atomically
  • Solution: Define an interface for composite objects that is shared with the atomic objects it composes
  • works well with the strategy pattern, as certain strategies may just be several simpler strategies applied together (e.g. discounts)
  • when using composites, it’s generally a good practice to pass around the composites instead of digging out the children (components). Composite Pattern done well supports this.
  • e.g.: Pattern-based design in context

Facade

  • Problem: There are many components in a subsystem, each with some behaviour that is needed, but knowledge of this subsystem or access to the other behaviour is not
  • Solution: Define a single point of access that provides an interface on the desired behaviours and encapsulates knowledge of the weird subsystem so nothing else has to know about it.

Observer/Subscriber

  • Problem: Different things want to know about different events and will behave in different ways, but low coupling is desired
  • Solution: define subscribers via an interface that listen, and then have them register to listen to publishers of events that they care about. The publishers will notify the correct subscribers at the correct times.
  • Frequently use in UIs

References

[1] Craig Larman. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development. Addison Wesley, 3rd edition, 2013

Architecture

Architecture

  • "In its simplest form, architecture is the structure or organization of program components(modules), the manner in which these components interact, and the structure of data that are used by the components" [1, p.223]
  • "The logical architecture is the large-scale organization of the software classes into packages (or name spaces), subsystems, and layers"[2, p.199]
  • "Architecture is what you have left when you take away everything you don’t need to explain how the system works" [3, p.393, by way of Krutchen]

Architecture as Structure [2, 197-201]

  • A key focus in Larman is the organization of code, via package diagrams, into layers to communicate project structure.
  • This logical organization to communicate structure still applies exactly the same way with other styles besides the layered style.

Architecture as Risk

  • Complex or high risk issues should be highlighted in the architecture
  • These often end up being structural issues, or at least can end up being thought of that way once they are understood.

Software Architecture Documents

N+1 View Model [2, p.655]

  • To learn about a system architecture, we need to look at it in different ways
  • Larman describes what has evolved into the N+1 model for doing so, with each of N being one of the ways to look at the system
  • The +1 represents key architectural use cases

Architectural Recap

  • We are concerned with the overall important structure of the system
  • We are concerned with risk areas of the system.

Views [2, 657-659]

Not all need be included, use the ones that communicate about architecturally relevant things

  • Logical
    • Conceptual organization of the software in terms of important layers, subsystems, packages, frameworks, classes and interfaces
    • Summarizes functionality of major software elements
    • Communicate use case realizations as interaction diagrams (usually sequence diagrams) to illustrate key aspects of the system
    • Shows an important subset of the system design, generally by way of class diagrams and interaction diagrams.
  • Process
    • Processes and threads, their responsibilities, collaborations and allocations to elements described in the logical view.
    • In a webapp, what do we know about Threads/Processes?
  • Deployment
    • A description of the physical deployment of processes and components to the various processing nodes of your system
    • A description of the network configuration between nodes
    • You can do a lot on the client-side.
  • Data
    • Overview of data flows, persistent data schemea, any object relational mappings between persistent data and in-memory objects.
    • Communicate important stored-procedures or triggers
  • Security
    • Overview of security schemes, points within the system (and architecture) where security is applied.
  • Implementation
    • A view on not just the software code as given in the logical view or design, but including libraries and resources, all organized by their physical location in the system (folder structure)
    • Explanation of why should supplement any diagrams of file layout, etc.
    • For example, a new member of a software team could use this view to guide their understanding of where files go and why they are organized in a given way.
  • Development
    • Description of the running and testing of the system.
    • Also covers things like revision control usage and policies
    • repo usage, convention and continious integration setup is appropriate here.
    • Should probably also cover coding conventions, though not listed in Larman.
  • Use Cases
    • Summary of most architecturally significant use cases
    • Probably duplicate the UCM, but only showing those important UCs.
    • Explanation of why and how are important, the diagram is just for convenience.

References

[1] Roger Pressman. Software Engineering: A Practitioner’s Approach (7th ed.). Pearson, 2010.

[2] Craig Larman. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development. Addison Wesley, 3rd edition, 2013.

[3] Dean Leffingwell. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Pearson, 2011.

Personal Software Process

Software Engineering As a Discipline

Personal Software Process

  • Encapsulates the BOK for a process-improvement method
  • Approach geared it easy to certify
  • Most importantly, it makes better Software Engineers

Personal Software Process Goals

  • Developers able to self-asses
  • Developers able to improve their skills
  • Employers are able to test employee competence at assessment/improvement

Personal Software Process Areas of Application

  • Concentration on Software Development
  • Can be applied to all parts of the software lifecycle
  • Can be applied outside of Software Engineering

Personal Software Process Terms

  • Key Concepts: Any facts, terminology, philosophy
  • Skills: The ability to interpret or apply Key Concepts to a task
  • Knowledge Area: Key Concepts and related Skills, or the area of understanding gained by their application
  • Competency Areas: Closely-related Knowledge Areas
    • Foundational Knowledge
    • Basic Personal Software Process Concepts
    • Size Measuring and Estimating
    • Making and Tracking Project Plans
    • Planning and Tracking Software Quality
    • Software Design
    • Process Extensions and Customization

Foundational Knowledge

  • Process Definition
  • Process Elements
  • Statistical Elements

Process Definition

  • Process: be able to plan and execute specific steps to do a specific task
  • Defined Process: be able to identify, document a process that is done repeatedly and is required for a job. Generally must be repeatable, even by others.
  • Benefits: understand that this leads to better planning/tracking/managing:
    • Can evaluate whether work is, done, how much has been done and how correctly it has been done objectively
    • Smooths coordination within a team
    • Allows better support between team members
  • Process documentation: can produce succinct written representations of process. Not a tutorial. Enough for an expert.
  • Processes and plans: can produce plans, which includes resource/role management, understanding the specific applications of a process for a given project, and other high-level concenrs:
    • schedules
    • budget
    • goals
    • commitments
    • identified risks
  • Personal process: can make a set of steps for one’s own workflow to guide work self-evaluation and self-improvement
    • based on own experience
    • modified from some other process
  • Enactable and operational processes:
    • Enactable: can define how to do a process in terms of what’s needed and what will result
    • Operational: can define what to do, like a tutorial on a process to guide a knowledgeable professional through that task. Enough detail to plan and track around (Personal Software Process is an operational process)
  • Process phases: can break down a process into phases (effectively sub-processes) as needed. At a minimum, phases are planning, development and postmortem
    • Planning: Produce a plan to do the work.
    • Development: Perform the work.
      • Define the requirements
      • Design the program
      • Review the design and fix all defects
      • Code the program
      • Review the code and fix all defects
      • Build or compile and fix all defects
      • Test the program and fix all defects
    • Postmortem: Compare actual performance against the plan, record process data, produce a summary report, and document all ideas for process improvement.
  • Incremental development: Each thing you do can be a Personal Software Process project, be it adding a simple feature or building a complex subsystem... even the whole project.
  • Process tailoring: be able to re-use existing processes appropriately for a particular purpose
  • Process building and refining: learn to build your own process toolkit and refine these and other Personal Software Process "Scripts" that you use.
Edit this page
Last updated on