代写代考 CSCI321 about week-7 of session-1.

Rational Unified Process (RUP)
Examples and illustrations from various sources at Rational, other parts of IBM’s “developerworks” site and the reference text
The Rational Unified Process: An Introduction: P Kruchten
(Available as electronic resource via Uni library)

Copyright By PowCoder代写 加微信 powcoder

“Software Development for Small Teams: A RUP-Centric Approach”, G. Pollice, L. Augustine, C. Lowe, J. Madhur.

Software process models Review

RUP: a process model
• RUP: a model for a software development process
• RUP is deliberately flexible – RUP is to be tailored to the needs of your project.
• The model is the defining core of RUP – Four phases
– Multiple activities
– Iterations

RUP: Best practices
• Six principles to follow when designing any software project to minimize faults and increase productivity:
1. Developiteratively
2. Managerequirements
– Always keep in mind the requirements set by customers and will be changed by users.
3. Usecomponents
– Test individual components and reusability.
4. Modelvisually
– Use diagrams to represent all major components, users, and their interaction. UML.
5. Verifyquality
– Always make testing a major part of the project at any point of time.
6. Control changes
– A project may be created by teams, sometimes in various locations, different
platforms may be used, etc. As a result it is essential to make sure that
4 changes made to a system are synchronized and verified constantly.

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.

The essence of RUP
Inception Elaboration Construction Transition
Minor Life-Cycle
Milestone Objective Milestone
Life-Cycle Architecture Milestone
Initial Operational
Capability Milestone
Product Release

RUP building blocks
• Roles (who) – A Role defines a set of related skills, competencies and responsibilities.
• Work Products (what) – A Work Product represents something resulting from a task, including all the documents and models produced while working through the process.
• Tasks (how) – A Task describes a unit of work assigned to a Role that provides a meaningful result.

Running example PSP tools
• PSP Tools is a software application that automates data gathering and reporting to help software engineers work with the Personal Software Process (PSP) more effectively.
• PSP Tools provides a place to record data related to your project. For each task you perform, PSP Tools allows you to track information in terms of Time, Defects, and Code Size.
• The team that developed PSP Tools has 4 people (Gary, Liz, Chris, and Jas) and there was one customer (Russell).
• They followed RUP to develop PSP Tools
“Software Development for Small Teams: A RUP-Centric Approach”, G. Pollice, L. Augustine, C. Lowe, J. Madhur.

Start at Inception
Mostly requirements, a little analysis and design –
identify the most important “use cases”, evaluate possible architectures.
Support roles concerned with putting
in place infrastructure (project management tools, development systems etc) as these are identified.

Inception objectives
• Establish the project’s software scope and acceptance criteria (requirements) .
• Establish the main use-case scenarios that define the core functionality of the project.
• Evaluate alternative architectures; create the beginnings of your preferred candidate architecture.
• Estimate the overall cost and schedule for the project.
• Estimate risks
• Produce the “business case” – what is the business justification and benefit from having the functionality provided.
• Create a work plan for the following elaboration phase

Inception activities
• Formulate the scope of the project: capture the context and the most important requirements and constraints
• Plan and prepare a business case
• Evaluatealternativesforriskmanagement, staffing, project plan, and trade-offs among cost, schedule, and profitability.
• Synthesize a candidate architecture

Inception outcomes
• A vision document
– the core project’s requirements, – key features,
– main constraints
• List all use cases and actors already identified
• An initial business case, which includes the following:
– Business context
– Success criteria (revenue projection, market recognition, and so on)
– Financial forecast
• An initial risk assessment
• An initial project plan, which shows the phases and iterations

Inception – The Life-Cycle Objective Milestone
– Stakeholder concurrence on scope and costings
– Requirements understanding evident through use cases
– Credibility of cost & schedule estimates, priorities, risks and development process
– Depth and breadth of prototype architecture
– Actual vs planned expenditure

PSP-tools Inception : Vision document
• What problem are we trying to solve? (Problem Statement)
• Who are the stakeholders?
Who are the users?
What are their respective needs?
• Whataretheproductfeatures?
• What are the functional requirements? (Use Cases)
• Whatarethenon-functionalrequirements?
• Whatarethedesignconstraints?

PSP-tools: Problem statement
“describe the problem, who it affects, how it affects them, and what type of solution would ease the pain.”

PSP-tools: “Position statement”
If you could develop software that would solve the problem described in the Problem statement:
who would buy it
and what would make it unique
16 Inception

Identify stakeholders
• Reminder: Stakeholders (SH) are persons or organizations. They may be affected by it either directly or indirectly.
• PSP-tools stakeholders were the team members and the customer Russell
17 Inception

Identify some features
• PSP-tools:
– “record personal statistics” • Time
• Software defects • Source code size
– “reporting”
• Personal reports • Team reports
– Viewing – Statistics –…
18 Inception

Sketch some high level use cases
• Software Engineer will use PSP-tools to:
– Create project
– Enter data
– Count items
– Use on line help when needed – Create report
Process administrator will use PSP-tools to:
– Configure system
– Configure project
– Install PSP-tools
– Use on line help when needed – …
19 Inception

Iterate a bit with your initial use cases!
• PSP-tools team reduced that initial use case diagram down to this:
20 Inception

PSP-tools : Inception
• “Iteration plan” for rest of inception phase
– Artefact, who responsible, when due
21 Inception

Initial Project Plan
PSP tools initial plan
1. Plan done by 10th Oct
2. Environment set up …
3. Vision complete by …
4. Supplementary requirements
5. Initial use cases by ..
6. Risk list
7. Test plan
8. Finish “Inception Iteration”
22 Inception

Flashback quiz
• Which of the following is a phase in RUP?
A. Inception
B. Elaboration C. Construction D. Transition
E. Iteration

Elaboration
Requirements continue
to be refined and additional use cases will be identified. But now more into getting
a baseline architecture, and working from use cases to ideas for classes and their interactions.

Elaboration – objectives
• Elaboration objectives:
– Define, validate, and baseline the system
architecture
– Baseline the vision.
– Baseline a plan for the construction phase.
– Demonstrate that the baseline architecture will support this vision for a reasonable cost in a reasonable time.
“baseline” – they mean create it, where relevant make it work, put it under version control! 25

Elaboration activities
– Finalize the “vision”
– Develop solid understanding of critical use cases.
– Put in place development environment, tools, test automation systems, etc.
– Elaborate the system architecture:
• Select subsystems that can be purchased (COTS – Common Off the Shelf software)
• Integrate and assess the selected components against primary use cases.

Elaboration outcomes
• A use-case model (at least 80% complete) in which all use cases have been identified in the use-case model survey, all actors have been identified,
– Most use-case descriptions have been developed
• Supplementary requirements that capture the non-functional
requirements
• A software architecture description
• An executable architectural prototype
• A revised risk list and a revised business case
• A development plan for the overall project, showing both major and minor iterations and stating deliverables at the completion of each iteration
• A preliminary user manual (optional)

Elaboration – Life-Cycle Architecture Milestone
– Is the product vision stable?
– Is the architecture stable?
– Does the executable demo show that major risk elements have been addressed and resolved?
– Is the construction plan sufficiently detailed?
– Do all stakeholders agree that the current vision can be achieved with the current development plans?

PSP-tools: Elaboration Iteration Plan
Note defining tests – some members started thinking about acceptance tests (use the system to perform tasks – “black box” testing), others thinking about unit tests (“white box
29 Elaboration
Who is John?
Oh, he withdrew from CSCI321 about week-7 of session-1.
We had to finish without him.

PSP-tools : elaborate the use cases
• Normalflowofevents(partofusecase description)
“Open project use case”
30 Elaboration

Initial classes and sequence diagrams
• Initial classes/objects: mainFrame”, “openDialog”, “openManager”, “databaseFactory”, “PSPDatabase”
• Draws up an initial UML sequence diagram
31 Elaboration

PSP-tools : system architecture
32 Elaboration

PSP-tools : User Interface Design
Tabbed pane – panels for different “data entry forms” and responses
Elaboration

Database design
PSP-tools database model
34 Elaboration

PSP-tools Entity classes
35 Elaboration

PSP-tools group adopts “Test Driven Development” strategy
• They created their unit test cases
• For example
– They plan a class PSPUser
• Ithasname,andloginnamefields,thesetobesetbythe constructor
• Itwillhavean“equals”operation
• TwoPSPUsersare“equal”iftheycontainsamestringsintheir name fields, and in their loginname fields
– Hence test
public void testEquals() {
PSPUser u = new PSPUser(“ ”, “gpollice”); Assert.assertTrue(u.equals(new PSPUser(“ ”,
“gpollice”);
36 Elaboration

Construction
Coding and testing,
more coding and testing, delivering iterated versions so some deployment and configuration;
lots of version management; elaborating the environment,
Hopefully not too much requirements, analysis, design – but you cannot escape project creep

Construction
• The Construction Phase
– Develop remaining components and application
– Integrate all parts into the product – Test all features thoroughly.
– Achieve useful versions (alpha, beta, and other test releases) as rapidly as practical

Construction – Objectives
• Minimized development costs by optimizing resource usage and avoiding unnecessary changes, scrap and rework.
• Achieving adequate quality as rapidly as is practical
• Achieving useful versions as quickly as possible.

Construction activities
• Resource management, resource control, and process optimization
• Complete component development and testing against the defined evaluation criteria
• Assessment of product releases against acceptance criteria for the vision

Construction – Initial Operational Capability Milestone
• Is the product stable and ready to be exposed to the user environment?
• Are the stakeholders ready for the product transition into the user environment?
• Are the actual resource expenditures still acceptable relative to the projected expenditures?

Construction iterations are planned!
• Your plan (started during Inception and refined in Elaboration) will have defined a series of iterations
– Each Iteration
• List of use-cases that it incorporates
• Time schedule (time boxing)
• Leads to a “build” that can be release to others

Iteration releases – a chance to replan
• With each iteration release, you revise your plan
– Maybe you are lagging – need to reduce the scope?
• Move some features from next phase to later phase
– Maybe you have negative feedback from the users/customers:
• Re-analysis, re-design, re-work

How long is an iteration?
• Depends on project size!
For CSIT321 projects;
– 4-6 persons
– Iteration time of three to four weeks – 3 iterations in construction
Lines of Code
5,000 20,000 100,000 1,000,000
Number of People
4 10 40 150
Duration of an Iteration
2 weeks 1 month 3 months 6 months

PSP Tools Construction The first iteration
• An executable architecture that actually does something
– A user of the PSPtool program construction-version-1 could
• Open an existing database
• Add time records and defect records
– still only stored in memory (no persistence to database!)
– Appear in tree view, can be processed when generating summary reports
• View totals (simple summary reports) in tabbed pane panels
45 construction

Construction – a first iteration
46 construction

PSP Tools Construction Iteration 2
• Features
– Help menu (actually no help at this stage, simply the “About PSP-Tools” dialog!)
– Improved Project-menu/ dialog
– “Prettier” dialogs
• (Greater experience with javax.swing classes)
– Develop database tables
47 construction

PSP Tools Construction Iteration 3
• Features
– Create a database from within PSP-tools
– Right-click pop-up “context sensitive” menus associated with tree view
48 construction

Iteration[*]
Functionality Added
Incorporated activity time and defect entries. Also implemented activity timer that updates the database directly. Implemented ability to update task summary information directly from the task summary panel.
Added line counter tool to the program. Improved login dialog. Removed need to run with a Cloudscape database server.
Installed database schema changes and automatic database upgrade mechanism. Added the Database Properties dialog box.
Added basic export function. Made user information editable.
Added program size and estimation tab.
Added ability to delete a task.
Delivered a self-extracting archive that unpacked the required files into a target directory and removed dependencies on the user’s environment.
Fixed defects. Released an initial User’s Guide.
Added an executable program for Windows that launched PSP Tools. Users no longer needed to run a
batch file, and extra windows no longer appeared on the user’s task bar.
Construction – Iterations 4-12

Transition
Hopefully no more changes in requirements, or design!
Hopefully also not much more implementation!
There will be overall testing to do, and some details of deployment to complete.
There will be quite a lot of work on setting up for use of populated databases, parallel running with existing software, phase out of existing system.

Transition
• Transition phase
– move the software product to the users
• Phase starts when system is mature enough to be deployed in
the end-user domain.
– Usable subset of the system has been completed to an acceptable
level of quality
– User documentation is available
• Phase includes:
– Beta testing to validate the new system against users’ expectations
– Parallel operation with the legacy system that the project is replacing
– Training of users and maintainers
– Rollout of the product to the marketing, distribution, and sales teams

Flashback quiz
Which of the following software development process models having difficulties in responding to changing customer requirements?
A. Iterative/incremental model B. Prototyping model
D. Waterfall

程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com