prj566 project planning & management software architecture

PRJ566 Project Planning & Management

Software Architecture

Systems Development Lifecycle (SDLC)

Projects are developed according to a definite methodology called the SDLC

Three major activities Analysis: understanding business needs Design: conceptualizing computer-system

solution Implementation: construction, testing, and

installation

Systems Development Lifecycle (SDLC)

Two additional phases: Project planning Support

Aids to Assist in Analysis and Design

Methodologies Comprehensive guidelines to follow for completing every SDLC

activity Collection of techniques Examples: Structured, OO

Models Representation of an important aspect of the real world Diagrams and charts Project planning aids

Software Architecture

Architectural Design Focuses on the overall structure of the system, the

relationships among its major components and their interactions

Is divided into sections or views

Models and Views Models are complete representations of the

system: use case models, class diagrams Architectural views focus only on what is

architecturally significant

The Architect The person responsible for the overall

structure and design of the system In a small system the architect may serve the role

of the analyst and the software designer, Programmer/Analyst

Should be the most senior and responsible person on the technical team

The Architect Becomes the owner of the technical vision

and his/her understanding of the overall system, coupled with his/her ability to to design a model of the system, is critical to the success of the project

The Architecture Document Designed to establish the overall structure of

the entire project by describing various architectural views

Architectural Views A view is a specific perspective or focus.

Typically an architectural view is a subset of the entire architecture.

Architectural Views The 4 + 1 View Model developed by Philippe

Krutchen

The 4 + 1 View Model developed by Philippe Krutchen

Use Case View Has precedence over the other views, because

the use case view--the collected use cases from the requirements analysis--drives and motivates the rest of the design.

Use Case View It is the job of the architecture and ultimately

the implementation to realize the use case requirements

Focus is on the interaction of the classes and how these interactions serve to implement the use cases we analyzed previously

Logical View Represents the organization of the most

significant classes and how they relate to one another

The class design is integrated into the logical view, creating an integrated perspective of the entire system

Logical View Most comprehensive architectural view Incorporates the most significant aspects of

all other views Provides an overview of the entire

architecture, and in conjunction with the code itself, provides a guide to the software

Process View Focuses on how, in a system with

multithreading or multiple processes, the concurrent tasks interact

Copyright © 1997 by Rational Software Corporation

The Physical World

Component diagrams illustrate the organizations and dependencies among software components

A component may be A source code component A run time components or An executable component


Course CourseOffering

Student Professor

Component Diagram

Course.dll

People.dll

Course

User

Register.exeBilling.exe

BillingSystem


Deploying the System

The deployment diagram shows the configuration of run-time processing elements and the software processes living on them

The deployment diagram visualizes the distribution of components across the enterprise.

Deployment View Focuses on the physical allocation of

resources and the allocation of tasks among those resources in a distributed system


Deployment Diagram

Registration Database

Library

Dorm

Main Building

Implementation View Embodied in the code with its supporting

documentation

How are architectural goals to be achieved?

Model software objects after problem domain objects

Build software systems like hardware systems, i.e. more pluggable

View programming as assembling parts

How are architectural goals to be achieved?

Build new software parts by extension “Grow” software systems through iterative

development Achieve large-grain interoperability across

heterogeneous systems and networks

Iteration Across Life Cycle Phases

The Spiral Life Cycle Model

Phases can be broken into smaller pieces, each with a different type of risk


Inception Elaboration Construction Transition

Iteration 1 Iteration 2 Iteration 3

Iteration PlanningRqmts Capture

Analysis & DesignImplementation

Test Prepare Release

“Mini-Waterfall” Process

Use Cases Drive the Iteration Process


Work Allocation Within an Iteration

Work to be accomplished within an iteration is determined by The (new) use cases to be implemented The rework to be done

Packages make convenient work packages for developers High-level packages can be assigned to teams Lower-level packages can be assigned to individual

developers Use Cases make convenient work packages for test and

assessment teams


The Iteration Life Cycle: A Mini-Waterfall

• Results of previous iterations• Up-to-date risk assessment• Controlled libraries of models,

code, and tests

Release descriptionUpdated risk assessmentControlled libraries

Iteration Planning

Requirements Capture

Analysis & Design

Implementation

Test

Prepare Release

Selected scenarios


Detailed Iteration Life Cycle Activities

Analysis & Design Determine the classes to be developed or updated in this iteration Update the object model to reflect additional design classes and

associations discovered Update the architecture document if needed Begin development of test procedures

Implementation Automatically generate code from the design model Manually generate code for operations Complete test procedures Conduct unit and integration tests


Detailed Iteration Life Cycle Activities

Test Integrate and test the developed code with the rest of the

system (previous releases) Capture and review test results Evaluate test results relative to the evaluation criteria Conduct an iteration assessment

Prepare the release description Synchronize code and design models Place products of the iteration in controlled libraries


Iteration Assessment

Assess iteration results relative to the evaluation criteria established during iteration planning: Functionality Performance Capacity Quality measures

Consider external changes that have occurred during this iteration For example, changes to requirements, user needs, competitor’s

plans Determine what rework, if any, is required and assign it to the

remaining iterations


Initial Project RisksInitial Project Scope

Revise Overall Project Plan• Cost• Schedule• Scope/Content

Plan Iteration N• Cost• Schedule

Assess Iteration N

Risks EliminatedRevise Project Risks• Reprioritize

Develop Iteration N• Collect cost and quality metrics

Define scenarios to address highest risks

Iteration N

Risk Reduction Drives Iterations


Three Important Features of the Iterative Approach

Continuous integration Not done in one lump near the delivery date

Frequent, executable releases Some internal; some delivered

Attack risks through demonstrable progress Progress measured in products, not documentation or engineering

estimates


Resulting Benefits

Releases are a forcing function that drives the development team to closure at regular intervals Cannot have the “90% done with 90% remaining”

phenomenon Can incorporate problems/issues/changes into future

iterations rather than disrupting ongoing production The project’s supporting elements (testers, writers,

toolsmiths, CM, QA, etc.) can better schedule their work

prj566 project planning & management software architecture

Documents