Tuesday, February 24, 2009

Software metric

is any type of measurement relating to a software system, process or related documentation;
it allows software and s. process to be quantified;
used for predictions or identifying anomalous components (to later analyse them)

metrics

we assume that software property can be measured and that there's a relationship between what we measure and what we want to know. we can only measure internal attributes (number of procedure parameters, length of user manual, no of error messages) but we need more often external attributes (maintainability, reliability, portability and usability)...

this measurement process is a part of quality control activity

once we have some measurements we can compare between projects

we choose the measurements to be made, we choose the components to measure

we sometimes want to find anomalous component to analyze them further

Data
  • should be collected immediately, most preferably automatically
  • dont collect unnecessary data
  • tell people why you collect the data
  • dont rely on memory, collect the data while it is generated not after project has finished
..all the time our goal is to predict the product quality

PRODUCT METRICS
  1. dynamic - in execution (measure efficiency & reliability; the metrics are close to those quality attributes)
  2. static - measure system representation (for measuring complexity, understandability, maintainability; metrics have to be indirect)
e.g. fan-in/fan-out (number of functions called from the function, or opposite), lenght of code, length of identifiers, depth of conditional nesting, average word length in document (whaaa?!), depth of inheritance tree (in object programming), number of overriding operations,..

//this is so stupid!

MEASURENMENT ANALYSIS
ok, we have the data but what does it mean
analysing collected data is very diffiicult (sommerville example: by increasing bug fixing we have more bugs - why? - not possible? - because more clients call and report them, because they see we fix them;p)
yes, reducing number of faults leads to increased help desk calls...

KEY POINTS
software quality management is about ensuring software meets required sandards
...
there's NO standarized and universally applicable software metrics

Certification of Software Engineering Professionals

//these slides are not from sommerville (i think).. and few texts I ve found int the internet by putting sentences from slides into google... so maybe he will not be so strict about details.. ?

Certification of Software Engineering Professionals ISO/IEC WD 24773

Certification - is a formal recognition that an individual has demonstrated proficiency within and comprehension of a specified body of knowledge at a point of time. It is not reigstration nor licensure (authrization). It is voluntary.
Why? because it is a mark of excellence, ensures the organization has
knowledge to ensure that recognized principles and practices of software engineering are being used. Plus competition in market.

--
BOKs and Organisations
INCOSE
The International Council on Systems Engineering
www.incose.org
Certified Systems Engineering Professional (CSEP)
SE Handbook (g2sebok.incose.org)
Finnish Chapter www.finse.org
IEEE
IEEE Computer Society
Certified Oftware Development Professional (CSDP)
www.computer.org
Software Engineering, eds. ...............SWEBOK
--
Background Requirements (CSDP)
1. Education
- baccalaureate or equivalent university degree
2. Experience
- 9,000 hours of experience in 6 of the 11 software engineering knowledge areas listed in the brochure
3. Proof of Professionalism
- review and acknowledge the Software Engineering Code of Ethics and Proessional Practice

... aaaaahhhhh stupid things and strange numbers... maybe this is irrelevant..:P
--
ok shortly:
there's some CSPD - certified software development professional
  • CSPD Cerfitication Examination that lasts 4 hours, on the computer, 180 questions from business practices, software requirements, s. design, s. construction and many others.., software configuration management
  • CSDP Recertification every 3 years - if within 3 years no exam, but you have to have 30 points for: employing SW engineer, gradute courses, publish papers, giving a presentation, professional activities...
  • software configuration management includes this at: the beginning of the life cycle, or predefined points at the lc, or at the end, and.. blabla
IPA Organization (from 1970, reorganized in Jan 5, 2004 as "Independent Administrative Agency")
  • originally to financially support development of software by credit guarantee, but later also computer security, human resource dvelopment, and others.
History of Examination
began from concern from the industry about shortage of IT engineers,
these engineers wanted recognition of their skills

first examination 1969
they expected 5000 people to take part, but there was 40000, out of whom 12000 passed as senior programmer and the rest with just 'programmer' grade. Becaause it turned out to be so popular it was raised to become a National Examination from 1970

1970 first National Exams held (hey, but in which country?)
1971 new category: systems engineer
1986 JIPDEC and JITEC (Japan IT Examination Center) appointed as the examination body
1994 11 categories
2002 +2 categories
2004 JITEC operation trasferred to IPA

* graph: //don't read this x, y this is just my interpretation :p
y: how many applicants and how many succesful applicants:
x: from 1973 to 2003
how many: from 1983 y=x, from 1990 y=-x, from 1995 y=2x, from 2002 down again
how m. successful: divide upper graph values by 10... actually not much difference over the time compared to the number of applicants... interesting.

* graph... nothing... haha just blank
every year approx 700,000 take the exams (in Japan?)

-----------------
ISO work on certification
-started in 2004
-new IS will be published in 2009
-ISO/EIC 24773
-general idea:
-national sheme<->IS
-national BOK <-> SWEBOK
-IS: Minimum experience
-code of practice / ethics (included)
- examination (depends..)
---
This International Standard applies to schemes intendedd to provide
certification for persons working as software engineering professionals. Such certification schemes may be created by national governments, by national or international professional organizations, or by private entities.
---
Knowlegde and skills
- body of knowledge
- the evaluation component of a certification scheme shall be explicitly based on a body of knowledge. For each component of this body of knowledge, the scheme shall state the cognitive level expected of a successful candidate for certification
---
Software Engineering body of knowledge
- the software engineering component of the body of knowledge required shall be explicitlymapped to :
- software engineering - Guide to the Software Engineering Body of Knowledge (SWEBOK) ISO/IEC TR 19759:2005
---
SWEBOK
-www.swebok.org
-.......oh so much text.
BUT haha google:
In spite of the millions of software professionals worldwide and the ubiquitous presence of software in our society, software engineering has not reached the status of a legitimate engineering discipline and a recognized profession. Since 1993, the IEEE Computer Society and the ACM have been actively promoting software engineering as a profession, notably through their involvement in the IEEE Computer Society and ACM Software Engineering Coordinating Committee.

guide to SWEBOK
TABLE OF CONTENTS
CHAPTER 2 SOFTWARE REQUIREMENTS
CHAPTER 3 SOFTWARE DESIGN
CHAPTER 4 SOFTWARE CONSTRUCTION
CHAPTER 5 SOFTWARE TESTING
CHAPTER 6 SOFTWARE MAINTENANCE
CHAPTER 7 SOFTWARE CONFIGURATION MANAGEMENT
CHAPTER 8 SOFTWARE ENGINEERING MANAGEMENT
CHAPTER 9 SOFTWARE ENGINEERING PROCESS
CHAPTER 10 SOFTWARE ENGINEERING TOOLS AND METHODS
CHAPTER 11 SOFTWARE QUALITY
CHAPTER 12 RELATED DISCIPLINES OF SOFTWARE ENGINEERING

---
Application area and dependence
-if the software engineering professional subject to certification is to operate in a particular industry or product domain, the certification body shall identify any appropriate knowledge requirements.
--
Generic professional skills
...

--
ThE future:
integration of knowledge on:
  1. Project (management)
  2. Process (improvement)
  3. Product (qualit)
  4. People (competence)
- the context of Software Engineering (SW) will move more towards Systems Engineering (SE)
-next big thing in SW will be connnected to people issues
-because of globalization, internationalization, lacalization (->will consider culture)\

--// END

Software product quality

to remind:

Talking about the quality we can talk either about the
-
process quality
or
-
product quality,
which are by the way related to each other (=>). The
product quality attributes (safety, security, reliability, testability, usability, ...) are hard to measure. We measure process quality. Process quality management involves: defining process standards, monitoring development process and reporting to software project to the project manager and the buyer of the software.

Three
quality management activities:
  1. quality assurance
  2. quality planning
  3. quality control
plus remembering that quality management process is independent from software development process and, it is done by different people.. (the graph)
  1. q. assurance - defining how software quality can be achieved and checked;
    it can establish:
    • product standards -> document standards (structure of requirements, documentation standards, and coding standards)
    • process standards -> specification of the processes (processes like validation, design, specification)
      ... bla bla bla....
  2. q. planning ...bla bla bla....
  3. q. control: may be done by
    • quality reviews - review team walks through the document with the author - takes lot of time
    • automated software assessment, which may involve measuring some software attributes
..and here we got to Software measurement and metrics :)..

from the slides:

Software product quality - not only having no defects (
reliable) but also satisfies other quality requirements, e.g. functionality and usability.

There are two series of standards:
  • ISO/IEC 9126 - Product quality (inside: quality model, external metrics, internal metrics, quality in use metrics) (from these metrics company can choose what they want)
  • ISO/IEC 14598 - Product evaluation (general overview, planning and management, process for developers, process for acquires, process for evaluators, evaluation module)

  • plus... we have some additional paper but no idea what it is.. IEEE P12207/CD3 ISO/IEC 12207...
And these two are integrated into SQuaRE = Software product Quality Requirements and Evaluation, to move the two main processes of requirements specification and quality evaluation into software quality measurement process...??

EXTERNAL and INTERNAL QUALITY and QUALITY IN USE

people quality => process q. => internal q. => external q. => quality in use

'=>' means 'influences'
for the last 4 we have metrcs
the last 3 we should measure (maybe 4 also...?)

8 CHARACTERISTICS OF SOFTWARE PRODUCT QUALITY (so proud of getting it ;P)
newer version of /*eee... this thick paper we got.. ISO/IEC JTC1/SC7/.... 23 Jan, .. somthing, somthing SQuaRE, somting, Quality models for sofware product quality and system quality in use............page 15*/
  1. funcitonal suitaibility
  2. reliability
  3. performance efficiency
  4. operability
  5. security
  6. compatibility
  7. maintainability
  8. portability
---
INTERNAL METRICS - applied e.g. to non-executable software product, during its development stages (e.g. request for proposal, requirements definition, design specification, source code, ..). It helps predicting the quality of the final product. It's done early and this is good.

EXTERNAL METRICS - when executing the software product in the system environment in which it is intended to operate.. done only during testing stages of l.c. or any operational stages..

QUALITY IN USE - user's view of quality
  • efectiveness
  • productivity
  • safety
  • satisfaction

Sunday, February 22, 2009

(probably) the second's exam scope

  • ------ no quality management
  • + Software product quality
  • + SPI - Software Process Improvement
  • + Measurement
  • + Managing people
  • + Plan-driven reference models
  • + The future of software processes

Monday, February 9, 2009

Quality management Do not mix with "software product quality"

Software quality is important. Should be paid attention to. But it is a complex thing.
It includes:
  • ensuring that required level of quality is achieved (internal and external(client) quality level)
  • defining quality standards
  • aim to develop a 'quality culture'; quality as everyone's responsibility
* when we sign up a contract, by agreeing on the quality we agree on the price - theses two go together - the customer should be explained that!
* how to measure quality? - surveys..

Quality = product meets its specification, but there are some problems with that applied to the software:
  1. except from user requirements we can have organization requirements that are not included in the specification
  2. it's hard to specify some characteristics in an unambiguous way (e.g. maintainability)
  3. meeting specification does not mean meeting user's expectations; this is because writing complete specification is hard
... so what we do? We resign from paying so much attention to specification, and we hire a person who does quality management ;p - now it's his problem;p
This
quality management is important especially for big systems.. we have then quality documentation over the time of development.. If the system is small we can make less documentation and focus just on "quality culture".

/*
if we want to create a "marching to the north culture" what do we do? If it's only us in the classroom it is enough to tell you: "let's march north!" but if we want to have more people across Finland, we have to send messages to them and set the date for example next Tuesday at 12am we start marching north */

*
quality management should be separate from project management ! - to have someone 'external'

QUALITY MANAGEMENT ACTIVITIES:
  • quality assurance - establish quality standards and procedures
  • quality planning - select applicable standards and procedures and modify if needed
  • quality control - ensure the standards and procedures are followed
.. the last two are at the project level //whatever it means.. something connected to the triangle..

** quality assurance is external to organization - we try to show customers we are good
** quality management is internal to organization - we try to be good ;p

We know that process => product. But where is the connection between process quality and product quality? - no one knows it;p
But, anyway, we assume there is the connection.. some connection.. so we should try to keep high process quality. How? Diagram: we improve process as long as the product is not good enough. If it is good we standardize the process (But even having standards we shouldn't use them if they're not appropriate..). Standards are the key to effective quality management. They may be national, international, organizational, ... . We can have product standards (e.g. common programming style) and process standards. They encapsulate best practices, help avoid repeating mistakes, provide framework for quality assurance processes, provide continuity so new staff knows what is going on.

PROBLEMS WITH STANDARDS:
-> may be seen as irrelevant, to much bureaucratic work, much work to associate documentation with the standard => we should motivate the developers ;p

--> wikipedia:

ISO 9000 is a family of standards for quality management systems. ISO 9000 is maintained by ISO, the International Organization for Standardization and is administered by accreditation and certification bodies. Some of the requirements in ISO 9001 (which is one of the standards in the ISO 9000 family) include

  • a set of procedures that cover all key processes in the business;
  • monitoring processes to ensure they are effective;
  • keeping adequate records;
  • checking output for defects, with appropriate and corrective action where necessary;
  • regularly reviewing individual processes and the quality system itself for effectiveness; and
  • facilitating continual improvement

A company or organization that has been independently audited and certified to be in conformance with ISO 9001 may publicly state that it is "ISO 9001 certified" or "ISO 9001 registered". Certification to an ISO 9000 standard does not guarantee any quality of end products and services; rather, it certifies that formalized business processes are being applied. Indeed, some companies enter the ISO 9001 certification as a marketing tool.


ISO 9000 is an international standard for quality management, applicable for many organizations; ... and so, for the ones that design, develop and maintain products there is ISO 9001 (from the ISO 9000 family) - generic model of quality process.

It concerns several things which I am too tired to describe and understand now.

To make our company ISO 9000 certified, an external body must do that. WHY oh why do we need the certification? Because our clients want it.

//There's a diagram on the slides..... zzzz.... my memory is becoming overloaded at this point..

  • Documentation standards
  • Quality planning
  • Software quality attributes (15)
  • Quality control
  • Quality reviews
  • Software measurement and metrics

Extreme programming - XP

This is the best known agile method.
  • requirements are expressed as scenarios = user stories, which are later broken down into tasks to implement
  • programmers work in pairs
  • test-first development (but when added new functionality we not only run new tests, but also all the previous ones)
  • incremental development, the releases are small and frequent (2 weeks), regular, continuous integration
  • full-time customer engagement in the development team; defining acceptance tests for the system; requirements; the user chooses the next story!
  • constant refactoring of the code! => keeping it simple and easier to change
  • everyone owns all the code (collective ownership)
  • no long working hours
XP release cycle:
  1. Select user stories for the release
  2. Break it down into tasks
  3. Plan the release
  4. Develop (and integrate) test software
  5. Release software
  6. Evaluate system
* the tasks are the basis for schedule and costs estimation

** Example:
-> user story - what he wants to do in the system, in order
-> 3 tasks - exactly how to perform the payment.. that you have to check that the credit card is valid, or the library card did not expire
-> task description - description in detail, what are inputs (also if string? integer?), what are the outputs, and description of algorithm: take the first four digits and check at the card's issuer, check if the expiry date is bigger then today's date, everything step by step...

Sunday, February 8, 2009

Agile methods

This is an answer to the plan-driven approach, which being good for large project was too heavy for development of smaller applications.
  • focus rather on software than the design and documentation
  • based on an iterative approach to software development
  • intended to deliver working software quickly and evolve quickly to meet changing requirements
.. they are probably best for small or medium-size business systems or PC products.

PRINCIPLES OF AGILE METHODS (5)
  1. Customer involvement - who prioritizes requirements, evaluates iterations of the system
  2. Incremental delivery - with the customer
  3. People not process - recognize team's skills
  4. Embrace change - expect change when designing
  5. Maintain simplicity - all the time eliminate complexity
Problems with agile methods:
  • difficult to keep interest of involved customers
  • team members should be suited to the intense involvement of agile methods
  • hard to prioritize with multiple stakeholders
  • maintaining simplicity requires extra work
  • contractual problems