COMP 325 Lecture 3: Processes and Workflows
major resources: Object-Oriented and Classical Software Engineering 6ed, Schach 2005, Object-Oriented Software Engineering, Schach 2008.

[ previous | schedule | next ]

Unified Process

• process encompasses paradigms and methodologies, life cycle models, tools, techniques, personnel
• Unified Process is name of predominant object-oriented methodology
• unification of several separately developed OO methodologies
• recall "three amigos": Grady Booch, Jim Rumbaugh, Ivar Jacobson (see http://c2.com/cgi/wiki?ThreeAmigos)
• Unified Modeling Language (UML) is Unified Process centerpiece
• full Unified Process is large and complex so it can be used for developing large and complex systems
• has five core workflows: requirements, analysis, design, implementation, test

Requirements workflow

• goal: determine client needs
• begin by identifying client constraints, or risks:
• technology constraints, such as quality (reliability, robustness) or environmental (size, response time) attributes
• budget constraints, which vary with client-developer relationship (fixed, developer bid)
• schedule constraints, with deadline fixed by client for a good reason
• developer needs to be or become familiar with application (client's) domain
• solution (developer's) domain is not relevant yet
• client does not always know what he/she needs
• client perceived needs may not match actual needs
• feasibility should be determined here
• results are documented in natural language

Analysis workflow

• goal: produce set of specifications acceptable to both client and developer
• goal: produce project management plan
• object-oriented analysis (OOA) involves discovering classes in client's world, their attributes, behaviors and relationships
• specifications are a contract between client and developer
• document must focus on what the system should do, not how it will be done
• document contents must be unambiguous so natural language is poor choice, use diagrams
• document must be readable and understandable to both client and developer
• statements must be precise (e.g. "system will respond within 1 second, 95% of the time")
• document must cover both functional (e.g. features) and non-functional (e.g. size, response time) requirements
• document must be detailed, so a design can be developed from it and implementation based on the design
• document should be complete, covering all aspects of the application
• both client and developer sign off on specification document
• if client and developer are from different organizations, contract law applies to specification document
• properly drawn specifications become source for acceptance tests
• specifications are used by developer for project planning and time/cost estimates
• project plan includes information such as
• development objectives
• the software process and life cycle to be used
• design, implementation, testing and maintenance tools and practices to be used
• organizational structure of the development team
• completion milestones, so progress can be measured
• detailed workflow schedules
• detailed budgets
• where do verification and validation come into play?

Design workflow

• goal: produce design that accurately reflects specifications and upon which implementation can be based
• designer translates client's world (specifications document) to developer's world (design documents)
• programmers use design documents as implementation guidelines
• tools and techniques depend on approach, with basic commonalities
• classical approach is define architecture then decompose into subsystems, then decompose subsystems into modules top-down; and design data structures
• object-oriented design (OOD) approach is identify and design classes, attributes, behaviors, relationships
• OO class is counterpart to classical module
• OOD classes are not necessarily same as OOA classes (its a "win" when they are)
• design should be done with maintenance in mind (hooks to facilitate perfective maintenance)
• design details need to be traceable back to specifications -- more on this later
• where do verification and validation come into play?

Implementation workflow

• goal: produce software that correctly implements the design
• implementors base their programs on the provided design
• implementation tasks are assigned to programmers according to methodology
• in classical view, subsystems are assigned to teams and their modules to individuals
• in OO view, classes are assigned to individuals/pairs
• integration must occur frequently - pull pieces together to make the whole
• where do verification and validation come into play?

Test workflow

• goal: ensure that the artifacts (products of work) in the other workflows are correct
• the test workflow happens in conjunction and in parallel with the other workflows
• developer should have software quality assurance (SQA) team for this
• much testing is done in review sessions, with client involvement at analysis workflow
• traceability is crucial
• elements of specification (analysis) must be traceable back to corresonding elements of requirement
• elements of design must be traceable back to corresonding elements of specification
• elements of implementation must be traceable back to corresonding elements of design
• tracing is facilitated by consistent numbering and cross-referencing across workflow documents
• common faults in all workflows are caught
• mismatch in details of corresponding elements from different workflows (verification)
• interface faults, such as parameter matches
• logic faults
• omissions
• much testing is done manually, such as tracing and verification of design details
• some same, some different testing tools and techniques apply in different workflows
• important tests associated with implementation include
• unit testing - testing individual methods/classes in isolation
• code reviews - programmers and SQA folks go over code line-by-line manually
• integration testing - pull classes/modules together and test the whole
• product testing - developer testing of implementation against specifications
• acceptance testing - client runs tests in real environment with real data
• alpha and beta testing - usually for COTS (commercial off-the-shelf), released to willing potential clients after product testing
• important test in maintenance is regression testing - after change is made, re-run all previous tests to assure the change didn't break something that previously worked!
• where do verification and validation come into play?

Unified Process Phases

• Two implementations of the Unified Process are
• Rational Unified Process (RUP). see http://www-306.ibm.com/software/rational/
• Enterprise Unified Process (EUP). see http://www.enterpriseunifiedprocess.info/
• Unified Process consists of phases as well as workflows
• The phases are sequential, the workflows parallel - all are present in each phase
• There are four development phases, nicely introduced at http://ootips.org/rup.html (questions courtesy of Dan Rawsthorne)
• inception phase: do you and the Customer have a shared understanding of the system?
• elaboration phase: do you have an architecture to be able to build the system?
• construction phase: are you developing product?
• transition phase: are you trying to get the Customer to take ownership of the system?
• There are also two post-deliver phases
• production phase
• retirement phase
• Inception Phase details
• goal is determine if the project is economically viable for all concerned
• emphasis on requirements workflow:
• understand client domain and build business model
• identify and prioritize as many risks as possible
• mitigate risks starting with the most critical
• some phase deliverables include
• initial domain and business models
• initial requirements documents
• preliminary analysis documents
• preliminary system architecture
• initial risks and use cases
• elaboration phase details
• goal is to flesh out, or elaborate, the inception phase results
• bulk of requirements and analysis workflows are completed here
• project planning is also done here
• some phase deliverables include
• completed domain and business models
• completed requirements and analysis documents
• updated system architecture
• updated risks and use cases
• project management plan
• construction phase details
• goal is to produce software ready for client testing (acceptance or beta)
• the bulk of design and implementation is done here
• lots of related testing is done here, particularly unit, integration, product
• some phase deliverables include
• beta version code
• preliminary manuals
• completed system architecture
• updated risks
• project management plan
• transition phase details
• goal is ultimate verification, assure product meets client requirements
• lots of testing is done here, mostly acceptance
• faults are corrected as discovered; there shouldn't be many since testing has been continual
• some phase deliverables include
• production version code
• completed manuals

Improving software processes through CMM

• CMM is Capability Maturity Model
• developed by SEI, Software Engineering Institute, in Pittsburgh - see http://www.sei.cmu.edu
• CMM for Software has been encorporated into family of models known as CMMI (CMM Integration)
• CMM has strategies for improving software processes
• CMM itself is not a life cycle or a software process
• CMM addresses software process management, not tools or life cycles
• CMM defines 5 maturity levels
1. initial: ad hoc
2. repeatable: basic management control
3. defined: process definition
4. managed: process measurement
5. optimizing: process control
• Level 1 characterized by lack of planning, unpredictability, staff-dependent processes
• Level 2 characterized by planning and project management based on past experience, and by use of measurements to identify and resolve problems
• Level 3 characterized by use of documented software process and by efforts to improve the process
• Level 4 characterized by setting quality and productivity goals for each project then taking appropriate measurements and using statistical analysis to identify and correct (process) problems as they arise.
• Level 5 characterized by continuous process improvement, using statistical analysis and process control techniques to not only address problems as they arise but to improve the software process for future projects
• Few organizations have achieved CMM Level 4 or 5, most are at Level 1. Level 3 is admirable.
• There are specific process aspects, called key process areas (KPA), defined for each maturity level above level 1.
• KPA are elements that developer needs to address to reach a given level.
• Certain contracts, particularly DoD, require minimum CMM level.