ACTIVITY DIAGRAM

1. OBJECT-ORIENTED EQUIVALENT OF FLOW CHARTS AND DATA FLOW DIAGRAMS (DFDS) FROM
STRUCTURED DEVELOPMENT

2. TYPICALLY USED FOR

• BUSINESS PROCESS MODELING
• MODELING THE LOGIC CAPTURED BY A SINGLE USE CASE OR USAGE SCENARIO
• MODELING THE DETAILED LOGIC OF A BUSINESS RULE
3. COULD POTENTIALLY MODEL
• THE INTERNAL LOGIC OF A COMPLEX OPERATION
• FAR BETTER TO SIMPLY REWRITE THE OPERATION SO THAT IT IS SIMPLE ENOUGH THAT YOU
DON’T REQUIRE AN ACTIVITY DIAGRAM
ACTIVITY DIAGRAM NOTATION
1. Initial node
8. Decision
• Filled circle = starting point of the diagram, not required
• A diamond with one flow entering and several leaving
2. Activity final node
9. Merge
• Filled circle with a border is the ending point, can have zero or • A diamond with several flows entering and one leaving, all
more activity final nodes. incoming flows must reach this point until processing continues,
3. Activity unless otherwise noted

• Rounded rectangles represent activities, may be physical or 10. Partition

electronic • Also called swim lanes, indicating who/what is performing the
activities
4. Flow/edge
11. Sub-activity indicator
• Arrows on the diagram
• Rake in the bottom corner of an activity indicates that the activity is
5.Fork
described by a more finely detailed activity diagram.
• A black bar with one flow going into it and several leaving it, 12. Flow final
parallel activity.
• Circle with the X through it, process stops at this point.
6. Join
13. Use case
• A black bar with several flows entering it and one leaving it, • Non-official? indication that an included use case is being invoked .
denotes the end of parallel processing.
UNIVERSITY ADMISSION EXAMPLE
APPLY TO
FILL OUT UNIVERSIT “SWIM LANES”
FORMS Y
ENROLL
APPLICANT
IN
[INCORRECT]
MUST BE ON LIST SEMINAR
INPUT INPUT OF APPLICANTS
FORMS APPLICANT [NOT ON LIST] BUT NOT IN SELECT
INFO SYSTEM APPLICAN
T FROM
REGISTRAR LIST

[NOT ON MATCH LIST ]

[ON MATCH LIST ]
[CORRECT]

CHECK [ON LIST]

CREATE
APPLICAN
STUDENT
DISPLAY CREATE T LIST
STUDENT SCREEN
SEARCH
FOR [NO MATCH]
SYSTEM
APPLICAN DISPLAY
T LIST OF
[POTENTIAL MATCHES’]
MATCHES
WHEN TO USE ACTIVITY DIAGRAM
Use activity diagrams when the behavior you are modeling ...
• Does not depend much on external events.
• Mostly has steps that run to completion, rather than being interrupted by events.
• Requires object/data flow between steps.
• Is being constructed at a stage when you are more concerned with which activities
happen, rather than which objects are responsible for them (except partitions
possibly).
 SOFTWARE ENGINEERING
PRESENTATION
SIDDHESH BHARAT PAWAR Group 7
QUALITY MANAGEMENT
 TOPICS COVERED
1. Process and product quality
2. Quality management activities
• Quality assurance and standards
• Quality planning
• Quality control
SOFTWARE QUALTIY MANAGEMENT

• Concerned with ensuring that the required level of quality is achieved in a software product.
• Involves defining appropriate quality standards and procedures and ensuring that these are
followed.
• Should aim to develop a quality culture' where quality is seen as everyone's responsibility.
 WHAT IS QUALITY ?

 Quality, simplistically, means that a product should meet its specification.

 This is problematical for software systems
• There is a tension between customer quality requirements (efficiency, reliability, etc.) and developer
quality requirements (maintainability, reusability, etc.);
• Some quality requirements are difficult to specify in an unambiguous way;
• Software specifications are usually incomplete and often inconsistent.

 Software quality management procedures cannot rely on having perfect

specifications.
PROCESS AND PRODUCT QUALITY

 The quality of a developed product is influenced by the quality of

the production process

 A good process is usually required to produce a good product

• For manufactured goods, this link is straightforward.
• But for software, this link is more complex and poorly understood
 PROCESS - BASED PRODUCT
QUALITY

Assess Product
Define Process Develop product
Quality

NO Quality
YE Standardize
Improve process ok S Process
 PROCESS - BASED PRODUCT
QUALITY
1. More complex for software because:
• The application of individual creative skills and experience is particularly
important in software development;
• Other factors also play a significant role in product quality;
• Software product quality attributes are hard to assess.
2. Care must be taken not to impose inappropriate process standards - these could
reduce rather than improve the product quality.
PRINCIPAL PRODUCT QUALITY FACTOR
DEVELOPMENT
TECHNOLOGY

PROCESS PRODUCT QUALITY PEOPLE

QUALITY QUALTIY

COST,TIME &
SCHEDULE
 QUALITY FACTORS
• For large projects with 'average' capabilities, the development process determines product
quality.
• For small projects, the capabilities of the developers is the main determinant.
• The development technology is particularly significant for small projects.
• In all cases, if an unrealistic schedule is imposed then product quality will suffer.
 PRACTICAL PROCESS QUALITY

• Define process standards such as how reviews should be conducted, configuration management,
etc.
• Monitor the development process to ensure that standards are being followed.
• Report on the process to project management and software procurer.
• Don't use inappropriate practices simply because standards have been established.
QUALITY MANAGEMENT ACTIVITIES
1. Quality assurance
• Establish organizational procedures and standards for quality
2. Quality planning
• Select applicable procedures and standards for a particular project and modify these
as required
3. Quality control
• Ensure that procedures and standards are followed by the software development
team
4.Quality management should be separate from project management to ensure
independence.
 QUALITY ASSURANCE AND
STANDARDS
1. Standards are important for effective quality management.
• Encapsulation of best practice - avoids repetition of past mistakes.
• They are a framework for quality assurance processes they involve checking
compliance to standards.
• They provide continuity - new staff can understand the organisation by understanding
the standards that are used.
 QUALITY STANDARDS

• Standards may be international, national, organizational or project

standards.
• Product standards define characteristics that all components should
exhibit e.g. a common programming style.
• Process standards define how the software process should be enacted.
 PROBLEM WITH STANDARDS
• They may not be seen as relevant and up-to date by software engineers.
• They often involve too much bureaucratic form filling.
• If they are unsupported by software tools, tedious manual work is often involved to
maintain the documentation associated with the standards.
 ISO 9000 CERTIFICATION

• Quality standards and procedures should be documented in an

organizational quality manual.
• An external body may certify that an organization's quality manual
conforms to ISO 9000 standards.
• Some customers require suppliers to be ISO 9000 certified although the
need for flexibility here is increasingly recognized.
DOCUMENTATION STANDARDS

1.Particularly important - documents are the tangible manifestation of the software.

2.Documentation process standards
• Concerned with how documents should be developed, validated and maintained.

3. Document standards
• Concerned with document contents, structure, and appearance.

4. Document interchange standards

• Concerned with the compatibility of electronic documents.
 QUALITY PLANNING

• The process of developing a quality plan for a project.

• A quality plan sets out the desired product qualities and how these are assessed and
defines the most significant quality attributes.
• The quality plan should define the quality assessment process.
• It should set out which organizational standards should be applied and, where
necessary, define new standards to be used.
 QUALITY PLANS
• Quality plan structure
. Product introduction;
. Product plans; Process descriptions;
. Quality goals;
. Risks and risk management.
• Quality plans should be short, succinct documents
. If they are too long, no-one will read them.
 QUALITY CONTROL

• This involves checking the software development process to ensure that procedures
and standards are being followed.
• There are two approaches to quality control
. Quality reviews;
. Objective software assessment and software measurement.
 QUALITY REVIEWS

• This is the principal method of validating the quality of a process or of a product.

• A group examines part or all of a process system and its documentation to find
potential problems.
• There are different types of review with different objectives
. Inspections for defect removal (product);
. Reviews for progress assessment (product and process);
. Quality reviews (product and standards).
 SOFTWARE MEASUREMENT
AND METRICS
• Software measurement is concerned with deriving a numeric value for an attribute of a
software product or process.
• This allows for objective comparisons between techniques and processes.
• Although some companies have introduced measurement programmes, most
organizations still don't make systematic use of software measurement.
• There are few established standards in this area.
 SOFTWARE METRICS
• Any type of measurement which relates to a software system, process or related
documentation .
• Lines of code in a program, the Fog index, number of person-days required to
develop a component.
• Allow the software and the software process to be quantified.
• May be used to predict product attributes or to control the software process.
 METRICS ASSUMPTION
• A software property can be measured.
• The relationship exists between what we can measure and what we want to know. We
can only measure internal attributes but are often more interested in external software
attributes.
• This relationship has been formalized and validated.
• It may be difficult to relate what can be measured to desirable external quality
attributes.