REK AYASA

PERANGK AT LUNAK
PERTEMUAN 10

A S R I M A S P U PA H , S . S . T . , M . T
 UMBRELL A
ACTIVIT Y
J U R U S A N I N F O R M AT I K A – F S I U N I V E R S I TA S
J E N D E R A L A C H M A D YA N I
2018/2019
PROPOSE UMBRELLA ACTIVITY
• Software engineering process framework activities are complemented
by a number of umbrella activities
• umbrella activities are applied throughout a software project and
help a software team manage and control progress, quality,
change, and risk
UMBRELLA ACITVITY APPLIED IN
SOFTWARE PROCESS
PROCESS IN UMBRELLA ACTIVITY
• Software project tracking and control—allows the software team to assess
progress against the project plan and take any necessary action to maintain the
schedule.
• Risk management—assesses risks that may affect the outcome of the project
or the quality of the product.
• Software quality assurance—defines and conducts the activities required to
ensure software quality.
• Technical reviews—assesses software engineering work products in an effort to
uncover and remove errors before they are propagated to the next activity.
• Measurement—defines and collects process, project, and product measures that
assist the team in delivering software that meets stakeholders’ needs; can be used
in conjunction with all other framework and umbrella activities.
• Software configuration management—manages the effects of change
throughout the software process.
• Reusability management—defines criteria for work product reuse (including
software components) and establishes mechanisms to achieve reusable
components.
• Work product preparation and production—encompasses the activities
required to create work products such as models, documents, logs, forms, and
lists.
SOFTWARE PROJECT TRACKING AND
CONTROL
1. Perform an adaptation criteria analysis—use selection scheme described
in Selecting on the Task Set for a Project
2. Select the software engineering task set—Define specific subtasks for the
project; define specific milestones and deliverables based on task set chosen.
3. Bound the scope of the software effort—determine project scope after
basic requirements have been identified.
4. Decompose product functionality—define major software functions
5. Estimate the size (in LOC or Function Point) of each product function.
6. Acquire historical data from development efforts for similar
projects/products.
7. Develop a project estimate using a task-function-effort table or a size-
oriented approach or empirical method (project effort and duration)
8. Estimate all project resources (i.e., people, skills, hardware, facilities,
etc.).
9. Develop a detailed project schedule—create a task network, a timeline
chart, resource tables and other scheduling information
etc see more info in http://www.rspa.com/apm/umtask01.html
RISK MANAGEMENT
1. Define technology and project risks.—review technology and
project risks defined during the scoping phase of the project
2. Identify project risks associated with scope.
3. Estimate the probability of occurrence for each risk—
indentify of generic and technology-specific risks.
4. Estimate the project impact of each risk, should it occur.
5. Develop a list of prioritized technology risks— sort the list
created in Task-2 through Task-4 by probability, then by impact.
6. Indicate a plan for technology risk mitigation, monitoring
and management (i.e., a contingency plan) and update
project planning information to reflect risks.
7. Revise project plan, if required—create a risk mitigation,
monitoring and management plan (RM3P) that is appropriate in size
and detail to the project category
SOFTWARE QUALITY ASSURANCE
1. Establish a Software Quality Plan for the project—develop a
Software Quality Plan that identifies those activities to be conducted
to ensure quality in deliverables produced in all CPF activities and
software engineering tasks
2. Establish a quality function deployment (QFD) scheme.
3. Establish validation criteria for the software to be produced
or modified.
4. Conduct reviews and other SQA activities as defined in Task-
2
5. Audit the software process to ensure that all quality issues
have been addressed and (where necessary) corrected.
TECHNICAL REVIEWS
1. Establish a review strategy before completing the project
plan.
2. Initiate formal technical reviews as project deliverables are
produced.
3. Conduct a formal technical review to uncover errors in a
software engineering deliverable—uncover errors in any work
product produced as a consequence of a software engineering task
4. Evaluate review results on a regular basis.
MEASUREMENT
1. Define the catalogue of project, product, and process metrics
that are to be collected—The catalog of metrics defines each aspect
of the project, the product and the process that is to be measured.
Measurement criteria, measurement points, and the analysis to be applied
for each metric are also defined
2. Define approach for analyzing metrics that have been
collected—Metrics will be analyzed at two levels. At the project levels,
metrics can be used to help the team improve its local process and the
product.
3. Collect metrics for the project, product, and process—Metrics
collection is an ongoing activity. A set of collection forms can be
developed for this purpose.
4. Analyze metrics for the project, product and process
5. Report analysis findings—The results of metrics analysis are reported
to a targeting audience that includes business management, project
management and technologists
SOFTWARE CONFIGURATION MANAGEMENT
1. Select an appropriate set SCM tasks—identify the change
management approach to be used.
2. Initiate change control process whenever a change is
requested that may affect a baselined deliverable—make a
change to a software deliverable in a controlled manner.
3. Record and report all changes to those individuals with a
need to know.
REUSABILITY MANAGEMENT
1. Adapt a set of reusability criteria and a classification scheme
for major project deliverables.
2. Define guidelines for creating reusable software components
(data, documents and programs) and train managers and
practitioners in their application.
3. Define reuse evaluation points (REP) on the project timeline.
4. Define candidate software components for entry into the reuse
library or candidate components for extraction from the
library.
5. Define specific SQA procedures for reusable components, prior
to their entry into the library.
6. Classify reusable components and enter them into the library.
7. Define specific validation procedures for reusable components,
subsequent to their extraction from the library.
8. Product Reuse Status Report (RSR)—indicates components that
have been reused from the library and reusable components produced by
the project team
WORK PRODUCT PREPARATION
AND PRODUCTION
1. Select the appropriate document outline for the software
engineering information to be documented.
2. dentify information created during software engineering
(CPF) tasks and required for the appropriate document.
3. Develop additional document content.
4. Construct the document.
5. Review the completed document for correctness.
 TERIMA KASIH
ADA PERTANYAAN ?

Referensi :
1. Roger Pressman.(2010), Software Engineering Seven Edition
2. http://www.rspa.com/apm/umtask05.html