software planning and requirement workshop

1. Software Project Management
Planning
Technical planning
Day 5

2. Recap
• Control plan
• Risk management plan
– Requirement control plan
– Schedule control plan
– Budget control plan
– Quality control plan
– Reporting plan
– Metric collection plan
• Project closeout plan
11/11/2011 2

3. Today
• Technical plan
– Process Model
– Methods, tools, and techniques
– Infrastructure plan
– Product acceptance plan
• Lab sheet 1
11/11/2011 3

4. Technical process plans
• This clause of the SPMP shall specify the
development process model, the technical
methods, tools, and techniques to be used to
develop the various work products:
– plans for establishing and maintaining the project
infrastructure
– the product acceptance plan
11/11/2011 4

5. Technical process - Process model
• Define the relationships among major project work
activities and supporting processes by specifying
– the flow of information and work products among
activities and functions
– the timing of work products to be generated
– reviews to be conducted
– major milestones to be achieved
– baselines to be established
– project deliverables to be completed
– required approvals that span the duration of the project.
11/11/2011 5

6. Technical process - Process model
• The process model for the project shall
include project initiation and project
termination activities.
• To describe the process model, a combination
of graphical and textual notations may be
used. Any tailoring of an organization’s
standard process model for a project shall be
indicated in this sub-clause.
11/11/2011 6

7. Software development models
• Waterfall model
• Spiral model
• Iterative and incremental development
• Agile development
11/11/2011 7

8. Software development methods
• Evolutionary Development model
• Model driven development
• User experience
• Top-down and bottom-up design
• Chaos model
• Evolutionary prototyping
• Prototyping
• ICONIX Process (UML-based object modeling with use cases)
• Unified Process
• V-model
• Extreme Programming
• Software Development Rhythms
• Specification and Description Language
• Incremental funding methodology
• Verification and Validation (software)
• Service-Oriented Modeling Framework
11/11/2011 8

9. Rational Unified Process (RUP)
11/11/2011 9

10. What is RUP?
• An underlying set of principles for successful software
development.
– These principles are the foundation on which the RUP has been
developed.
• A framework of reusable method content and process
building blocks.
– A family of method plug-ins defines a method framework from
which you create your own method configurations and tailored
processes.
• The underlying method and process definition language.
– A unified method architecture meta-model that provides a
language for describing method content and processes.
11/11/2011 10

11. RUP history
• Software process product that was produced
by IBM in Feb 2003
• Included in the IBM Rational Method
Composer (RMC) product which allows
customization of the process
11/11/2011 11

12. Poor software development
• User or business needs not met
• Requirements churn
• Modules do not integrate
• Hard to maintain
• Late discovery of flaws
• Poor quality or end-user experience
• Poor performance under load
• No coordinated team effort
• Build-and-release issues
11/11/2011 12

13. Tracing the root cause
11/11/2011 13

14. Enable Feedback by Delivering
Incremental User Value
• Divide the project into a set of iterations
– In each iteration, we perform some requirements, design,
implementation, and testing of the application, producing
a deliverable that is one step closer to the solution.
• Obtain feedback from stakeholders to find out:
– Are we moving in the right direction?
– Are stakeholders satisfied so far?
– Do we need to change the features implemented so far?
– What additional features need to be implemented to add
business value?
11/11/2011 14

15. Iterative Development Characteristics
• Resolves major risks before P P P
Iterative 1
Iterative 2
Iterative 3
making large investments.
• Enables early user
feedback. A A A
• Makes testing and
integration continuous. D D D
• Focuses project short-term
objective milestones. T T T
• Makes possible
deployment of partial
implementations. M M M
11/11/2011 15

16. Iterative Development Produce an
Executable
11/11/2011 16

17. Elements of RUP
11/11/2011 17

18. Process Structure
• Two dimensions.
• Horizontal axis represents time and shows the
lifecycle aspects of the process as it unfolds.
• Vertical axis represents core process
workflows, which group activities logically by
nature.
11/11/2011 18

19. The Development Phases
• Inception Phase
• Elaboration Phase
• Construction Phase
• Transition Phase
11/11/2011 19

20. Inception objectives
• Establish project scope and boundary conditions
• Determine the use cases and primary scenarios that
will drive the major design trade-offs
• Demonstrate a candidate architecture against some
of the primary scenarios
• Estimate the overall cost and schedule
• Identify potential risks (the sources of
unpredictability)
• Prepare the supporting environment for the project
11/11/2011 20

21. Inception activities
• Formulate scope of project
• Plan and prepare a business case and evaluate
alternatives for risk management, staffing,
project plan
• Synthesise a candidate architecture.
11/11/2011 21

22. Outcome of inception
• A ‘vision’ document, i.e., a general vision of the core projects
requirements, key features and main constraints.
• A Use-Case model survey – all Use Cases and Actors that can
be identified so far.
• An initial project glossary.
• An initial business case including business context, success
criteria and financial forecast.
• Initial risk assessment.
• Project plan, with phases and iterations.
11/11/2011 22

23. Evaluation criteria at end
• Agreement on scope definition and cost and
schedule estimates
• Requirements understanding as shown by the
correctness of the primary Use Cases.
• Credibility of the cost and schedule estimates,
priorities, risks and development process.
• Depth and breadth of any architectural prototype
that was developed.
• Actual expenditure v planned expenditure.
11/11/2011 23

24. Elaboration objectives
• Define, validate, and baseline the architecture as
rapidly as is practical
• Address architectural significant risks
• Baseline the vision
• Baseline a detailed plan for the Construction
phase
• Demonstrate that the baseline architecture will
support the vision at a reasonable cost in a
reasonable period of time
• Refine support environment
11/11/2011 24

25. Elaboration objectives
• Define, validate and agree the architecture as
quickly as possible.
• Agree the vision that came from the inception
phase.
• Agree a plan for the construction phase.
• Demonstrate that the architecture will
support this vision for a reasonable cost in a
reasonable time.
11/11/2011 25

26. Elaboration activities
• The vision is elaborated and a solid
understanding is established of the most
critical Use Cases that drive the architectural
and planning decisions.
• The Process, the infrastructure and the
development environment are elaborated,
and the process, tools and automation
support are put into place.
11/11/2011 26

27. Elaboration activities
• The architecture is elaborated and
components are selected.
– Potential components are evaluated.
– make / buy / reuse decisions determine the
construction phase cost and schedule.
– Architectural components integrated and assessed
against primary scenarios.
– This is done iteratively.
11/11/2011 27

28. Outcome of elaboration
• Executable architectural prototype.
• Revised risk list and revised business case.
• Development plan for overall project.
– coarse grained project plan, with iterations and
evaluation criteria for each iteration.
• Updated development case that specifies
process to be used.
• Preliminary user manual (optional).
11/11/2011 28

29. Evaluation criteria at end
• Is the vision of the product stable?
• Is the architecture stable?
• Does the executable demonstration show
that major risk elements are addressed?
• Is construction phase sufficiently planned?
• Do all stakeholders agree that current
vision is achievable, using current plan with
current architecture?
• Is the cost acceptable?
11/11/2011 29

30. Construction
• Complete the software product for transition
to production
• Minimize development costs by optimizing
resources and avoiding unnecessary scrap and
rework
• Achieve adequate quality as rapidly as is
practical
• Achieve useful versions (alpha, beta, and other
test releases) as rapidly as possible
11/11/2011 30

31. Construction objectives
• Minimise development costs by optimising
resources and avoiding unnecessary scrap and
rework.
• Achieve adequate quality as rapidly as
possible.
• Achieve useful versions (alpha, beta or other
test releases) as rapidly as practical.
11/11/2011 31

32. Construction activities
• Resource management, resource control,
process optimisation.
• Complete component development and
testing against the defined evaluation criteria.
• Assessment of product releases against
acceptance criteria for the vision.
11/11/2011 32

33. Outcome of construction
• A product ready to put into the hands of end
users.
• The software product integrated on the
adequate platforms.
• The user manuals.
• A description of the current release.
11/11/2011 33

34. Evaluation criteria at end
• Often called the beta release, is it ready?
– Is the product release stable and mature enough to be
deployed in the user community?
– Are all stakeholders ready for the transition into the use
community?
– Are the actual resource expenditures v planned
expenditures still acceptable?
• Transition may have to be postponed by one release
if the project fails to reach this milestone.
11/11/2011 34

35. Transition
• This moves the software project to the user
community.
• After release, issues usually arise that require new
releases, either to correct problems or finish features
that were postponed.
• This phase is entered when a baseline is mature
enough to be deployed in the end-user domain.
• This means that some usable subset of the system
has beem completed to an acceptable level of quality
and that user documentation is available.
11/11/2011 35

36. Transition phase includes
• Beta testing to validate the new system against use
expectations.
• Parallel operation with the legacy system that the
project is replacing
• Conversion of operational databases.
• Training of users and maintainers.
• Rollout of the product to the marketing, distribution
and sales teams.
• It concludes when the deployment baseline has
achieved the completed vision.
11/11/2011 36

37. Transition objectives
• Achieve user self-supportability.
• Achieve stakeholder concurrence that
deployment baselines are complete and
consistent with the evaluation criteria of the
vision.
• Achieve final product baseline as rapidly and
cost-effectively as practical.
11/11/2011 37

38. Transition activities
• Deployment-specific engineering, i.e. cutover,
commercial packaging and production, sales rollout,
and field personnel training.
• Tuning activities, including bug fixing and
enhancement for performance and usability.
• Assessing the deployment baselines against the vision
and the acceptance criteria for the product.
• The activities depend on the goal
– For fixing bugs, implementation and testing are usually
enough.
– For new features, iteration is similar to construction phase.
11/11/2011 38

39. Evaluation criteria at end
• Is user satisfied?
• Are the actual resources expenditures vs
planned expenditures still acceptable?
11/11/2011 39

40. Technical process -
Methods, tools, and techniques
• Specifies the following items:
– development methodologies
– programming languages and other notations
– the tools and techniques to be used to
• specify • document
• design • deliver
• build • modify
• test • maintain
• integrate
the project deliverable and non deliverable work products.
• In addition, the technical standards, policies, and
procedures governing development and/or modification of
the work products shall be specified.
11/11/2011 40

41. Methods
• What are the methods you are going to use in your
software development phases
• For example
– REQUIREMENT AND DESIGN: the project will be using
UML
– TESTING: will be done through white box testing and black
box testing
– SW TOOLS: Java, MS Office, MS Project, GPS Track Maker
13.5.409, Internet Explorer,
– HW TOOLS: PC and Peripherals
– PERSONAL SKILLS: Communication skills, XML, Java, SW
Engineering Processes, Review and Testing
Techniques, User Manual, Planning and Coordination.
11/11/2011 41