SPM

1.
Software architecture provides a design plan, a blueprint of a system, an

abstraction to help manage the complexity of a system, and also a communication
medium between stakeholders.
2. Critical factor for a product’s success: good software architecture that is

understood by the stakeholders and by the developers.
3. Structural plan that describes the elements of the system, how they fit together,
and how they work together to fulfill the system’s requirements.
Model based architecture
Management perspective
Technical perspective
Management prespective
• The most critical technical product of a software

project is its architecture:
• the infrastructure, control and date interfaces
that permit software components to co-operate
as a system and software designers to co-
operate efficiently as a team.
• If a software development team is to be
successful, the inter project communications, as
captured in the software architecture, must be
both accurate and precise.
From a management perspective, there are three
difference aspects of architecture.
• An architecture (the intangible design concept) is the
design of a software system this includes all
engineering necessary to specify a complete bill of
materials.
• An architecture baseline (the tangible artifacts) is a
slice of information across the engineering artifact
sets sufficient to satisfy all stakeholders that the vision
(function and quality) can be achieved within the
parameters of the business case (cost, profit, time,
technology and people).
• An architecture description (a human-readable
representation of an architecture, which is one of the
components of an architecture baseline) is an
organized subset of information extracted form the
design set model(s). The architecture description
communicates how the intangible concept is realized
in the tangible artifacts.
ARCHITECTURE: A TECHNICAL PERSPECTIVE
An architecture framework is defined in the
terms of views that are abstractions of the UML
models in the design set. The design model
includes the full breadth and depth of
information. An architecture view is an
abstraction of the design model; it contains
only the architecturally significant information.
Most real-world systems require four views:
design, process, component and deployment.
The purposes of these views are as follows:
Design: Describes architecturally significant structures and
functions of the design model.
Process: Describes concurrency and control thread
relationship among the design, component and
deployment views.
Component: Describes the structure of the
implementation set.
Deployment: Describes the structures of the deploy.
Generally, an architecture baseline should including the
following:
Requirements: critical use cases system-level quality objectives
and priority relationships among features and qualities Design:
names, attributes, structures, behaviors, groupings and
relationships of significant classes and components 33
Implementation: source component inventory and bill of
materials (number, name, purpose, cost) of all primitive
components Development: executable components sufficient to
demonstrate the critical us cases and the risk associated with
achieving the system qualities.
Workflow :
Series of sequential tasks those are performed to achieve
certain goals
Each workflow is defined by three parameters i.e. input ,

transformation , and output.
Software Process Workflows

It is the set of related activities those are performed to get
a software product as an outcome
This workflow leads the software developments in a linear way by

performing series of sequential tasks.
Planning guidelines and
cost of schedule
estimating
By : Shyamali
Planning Guidance
 Planning guidelines are generally written statement that

contains guidance to be referred before any development and
establishing take place of a project.
 It is valuable but risky to make specific planning
recommendations independent of project context.
 It is valuable because most people in management positions

are looking for a starting point.
Planning is an essential part of software engineering, and there are several

guidelines that can be followed to ensure that the software development
process is well-organized and efficient.
Some of these guidelines include:
• Define clear and measurable objectives

• Understand the requirements
• Create a project plan
• Identify and manage risks
• Define the software architecture
• Establish a development process
• Define the testing strategy
• Monitor and control progress
• Communicate effectively
Two simple planning guidelines should be
considered when a project plan is being
initiated or assessed.
• The first guideline, detailed in Table 1.1:

prescribes a default allocation of costs
among the first-level WBS elements.
• The second guideline, detailed in Table

1.2, prescribes the allocation of effort and
schedule across the life- cycle phases.
The second guideline,
detailed in Table 1.2,
prescribes the allocation of
effort and schedule across
the life- cycle phases.
Cost and schedule estimating process
Project plans need to be derived from two perspectives.
The first is a forward-looking: top-down approach:
 It starts with an understanding of the general requirements and constraints, derives a

macro-level budget and schedule, then decomposes these elements into lower level budgets
and intermediate milestones.
 From this perspective, the following planning sequence would occur:
a. The software project manager (and others) develops a characterization of the

overall size, process, environment, people, and quality required for the project.
b. A macro-level estimate of the total effort and schedule is developed using a

software cost estimation model.
The second perspective is a backward-looking, bottom-up
 You start with the end in mind, analyse the micro-level budgets
and schedules, then sum all these elements into the higher level
budgets and intermediate milestones.
 From this perspective, the following planning sequence would

occur:
a. Estimates are combined and integrated into higher level
budgets and milestones.
b. Comparisons are made with the top-down budgets and

schedule milestones.

SPM

Uploaded by

Copyright:

Available Formats

SPM

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SPM

Uploaded by

Copyright:

Available Formats

1.

Software architecture provides a design plan, a blueprint of a system, an

2. Critical factor for a product’s success: good software architecture that is

• The most critical technical product of a software

Each workflow is defined by three parameters i.e. input ,

Software Process Workflows

This workflow leads the software developments in a linear way by

 Planning guidelines are generally written statement that

 It is valuable because most people in management positions

Planning is an essential part of software engineering, and there are several

• Define clear and measurable objectives

• The first guideline, detailed in Table 1.1:

• The second guideline, detailed in Table

Project plans need to be derived from two perspectives.

The first is a forward-looking: top-down approach:

 It starts with an understanding of the general requirements and constraints, derives a

 From this perspective, the following planning sequence would occur:

a. The software project manager (and others) develops a characterization of the

b. A macro-level estimate of the total effort and schedule is developed using a

 From this perspective, the following planning sequence would

b. Comparisons are made with the top-down budgets and

You might also like