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

Prototyping (throw-away prototyping)

NOTE: this is similar to the idea of incremental development.. BUT: incremental development delivers a working system to the users, requirements should have been well understood beforehand, and throw-away prototyping we use to explore the requirements, the user just validates it; moreover the lifetime of an increment release may be much longer than the one of our prototype;

Throw-away prototype
-> not delivered to the user, not maintained
-> try out design, options, possible solutions
-> can be used before proper incremental development.. but does not have to
-> system stakeholders can experiment with it on early stages

There're three situations when we may want to use prototyping:
  • in requirements engineering process
  • in system design process
  • in testing process (back-to-back testing: ~we check if the prototype behaves in the same way as the application)

Rapid software development processess

RAD - rapid software development
- is designed to produce useful software quickly; it's iterative; specification, design, development and testing phases interleave. Software is delivered in a series of increments, each including new system functionality; some characteristics:
  1. processes of specification, design and implementation are concurrent
  2. incremental, while users and stakeholders are involved in specifying and evaluating each increment => accelerated delivery and users engagement with the system
  3. system UI often developed using iterative development
BUT: IID => management problems (not cost-effective to produce lots of documentation, unfamiliar technologies), contractual problems (no ready specification), validation problems (no ready specification again), maintenance problems (complex software's structure, people need to know RAD techniques)
-> not for huge systems where teams work in different locations, critical systems (?)

Triangle for "product" => businesses may be willing to accept software delivered quicker but with lower quality and essential functionality (mobile phones)

Saturday, February 7, 2009

Some notes from the first two lecutres

Three "S":
  • Services - what industry is selling; are provided by
  • Systems - package of different interacting software
  • Software - by creating the software we create some system
Three "P":
  • People - we, with different background
  • Project
  • Process
Software can have various
  • function
  • application area (e.g. university or a private company)
  • operation mode (e.g. how many users at a time)
  • scale (e.g. how many lines)
  • data representation (e.g. database type, file types)
  • software criticality
  • software stability
  • software product availability
  • computer system and environment
  • computer resource requirement
  • security requirement
  • reliability requirement
Triangle for "product"
- size = functionality
- quality
- time
-> this is the reason why we still have problems like during the 'software crisis' ('60)
-> NATO Conference 1969 recommends standardization of the software development process

Triangle for "quality"
- process (as skeleton to help people with different backgrounds;p)
- tools
- people

Sofware processes are in the development phase of the software life-cycle. - ?!

Evolution of s. process models:
  • Code-and-fix model ('50)
  • Stagewise model (from stage to stage, '60)
  • Waterfall model ('70)
  • Evolutionary model, Transform model, IID (~'80)
  • Spiral model ('80/'90)
  • Agile development, XP (~2000)
Types of development
  1. Plan driven development - document-driven, code-driven, traditional; emphasis on defining the scope, schedule and costs upfront;
  2. Change-driven development - aim of enabling evolution of product requirements during process of software development; adoption of IID approach;
  • Iterative development - often resulting as a internal iteration release (IIR), a stable, integrated, tested partially, complete system; each iteration may considered as a mini-project, produces a subset of the final system;
  • Incremental development - adding functionality to the system over several releases to the market; one incremental delivery may be composed of several iterations;
  • IID - when the system is developed in several iterations; often called just iterative development;p
NOTICE: in IID increments consist of several iterations each, not the opposite!

* Iterative development - many waterfalls; XP - plenty of waterfalls ;p

Four fundamental process activities

There are four fundamental process activities common to all software processes: click


1. Software specification (= requirements engineering)
- the process of establishing what services are required from the system, and identifying the constraints on the system's operation and development; leads to the production of a requirements document that is specification for the system;

Consists of following phases (page 75):
  • Feasibility study - ...
  • Requirements elicitation and analysis - ...
  • Requirements specification - ...
  • Requirements validation - ...
These phases are interleaved, they are not carried out in a strict sequence.


2. Software design and implementation
- the process of converting a system specification into an executable system; except from design and programming may also include refinement of the specification (in an evolutionary approach)

a) design - design of a structure that realizes the specification;
-> consists of activities:
  • architectural design
  • abstract specification
  • interface design
  • component design
  • data structure design
  • algorithm design
-> usually documented as a set of graphical models:
  • object model
  • sequence model
  • state transition model (how system's states change)
  • structural model
  • data-flow model (how data is changed and transformed)
b) implementation - translate this structure into an executable program; remove errors from that program;
debugging != defect testing
debugging: locate error -> design error repair (not to create more bugs!) -> repair error -> retest program

These two activities (design and implementation) are closely related and may be interleaved;

3. Software validation (verification and validation)
- intended to show that a system conforms to its specification and the system meets expectations if the customer buying the system; involves checking proceses: inspections and reviews at each stage of the software process

Testing stages:
  • Component (unit) testing - individual components are tested independently; components may be functions or objects, ...
  • System testing - the components are integrated; looking for errors resulting from interactions between the components; validating if system meets the functional and non-functional requirements
  • Acceptance testing - testing with customer data to check that the system meets the customer's needs

4. Software evolution (= software maintenance)
- software must be changing; this activity is when system is in use;

Iterative process models

The specification is developed in conjunction with the software. But this implies contractual problems.
* We can apply these models to any of the generic process models.
* The below models are not completely separate, they're related.


INCREMENTAL DELIVERY
- the software specification, design and implementation are broken down into a series of increments that are each developed in turn
- user requirements of high priority and are developed in early increments
- once increment started the current increment's requirements are frozen (but the later increment's requirements can still evolve)

STAGES:

  1. Define outline requirements
  2. Assign requirements to increments
  3. Design system architecture
  4. Develop system increment
  5. Validate increment
  6. Integrate increment
  7. Validate system
  8. if system incomplete: go to 4.
-> early increments work as prototypes
-> lower risk of overall project failure
-> highest priority services are most tested, because they're the earliest
-> users can use the system immidiately
-> increments should be of right size - difficult

* a variant of this development is XP development ;p



SPIRAL DEVELOPMENT (by Boehm, 1988)
- the development of the system spirals outwards from an initial outline through to the final developed system
- each loop in the spiral represents a phase in the process
- no fixed phases such as specification or design - loops in the spiral are chosen depending on what is required
- risks are explicitly assessed and resolved throughout the process

http://www.ics.uci.edu/~wscacchi/Software-Process/Images/Spiral-Model-Boehm-1987.gif

Each loop stands for different a phase in software process. For example the first loop could be concerned with system feasibility, second with requirements definition, next one with system designand, and so on.. Additionally, each loop consists of FOUR sectors:
  • Objective setting - defining phase objectives; identify constraints on the process; draw up a management plan; identify project risks; define alternative strategies based on that risk;
  • Risk assessment and reduction - detailed analysis of every identified project risk; take steps to reduce the risk;
  • Development and validation - choose development model (e.g. waterfall if main risk is sub-system integration, evolutionary dev. if user interface risks are dominant, ...)
  • Planning - review of the project, decision if we continue to the next cycle, if yes - plans for the next phase
-> explicit recognition of risk
-> we can decide after risk analysis if we want to continue or we should quit

Software process models

Software process models - they are abstractions, not definitive descriptions of software processes; kind of a framework.. these are the following: click


WATERFALL MODEL:

STAGES:

  • Requirements analysis and definition - by consultation with users; system specification
  • System and software design - establish overall system architecture
  • Implementation and unit testing - software design is realized as a set of program units; verify that each unit meets its specification
  • Integration and system testing - units are integrated and tested as a complete system if they meet the requirements
  • Operation and maintenance - usually the longest phase; system is in practical use; correcting errors; enhancing services as new requirements are discovered
* documentation is produces at each phase
* phases may overlap

-> it is easy to understand, that's why 60% companies use it
-> hard to change anything once it is underway
-> that's why we have to be 100% sure we understand the requirements, and that they don't change
-> used for large systems, while developed at many sites (it's easier to control them)
-> waterfall model gives control over the communication



EVOLUTIONARY DEVELOPMENT:

- work with customer to evolve a final system from an initial outline specification; two types:
a) Exploratory development - we should start with clearly specified requirements and add new features proposed by the customer;
b)
Throw-away prototyping - start with poorly understood user requirements, experiment with the customer requirements to understand them

STAGES:
  • Outline description
  • concurrently: Specification, Development and Validation
* we get initial version, then many intermediate versions, and in the end the final version

-> lack of process visibility (we don't know where we are)
-> systems are poorly structured
-> may require special skills (e.g. in languages for rapid prototyping)
-> for small or medium size interactive systems or parts of large systems (e.g. user inteface)
-> for short-lifetime systems



COMPONENT-BASED SOFTWARE ENGINEERING (CBSE)

- software reuse;

STAGES:

  • Requirements specification
  • Component analysis - search for appropriate components
  • Requirements modification - modify to reflect the available components; or go to previous step;p
  • System design with reuse - design framework for the software
  • Development and integration - integrate components, develop what is needed..
  • System validation
-> reduces the amount of software to be developed
-> reduces costs and risks
-> faster delivery
-> it may not meet the real needs of the users
-> no full control over the system evolution

COTS - is a term for software or hardware, generally technology or computer products, that are ready-made and available for sale, lease, or license to the general public.

Software processes (Chapter 4)

Software life-cycle (5) by Sommerville:
Requirements definition -> System and software design -> Implementation and unit testing -> Integration and system testing -> Operation and maintenance

Software life-cycle (3+2) by Tukiainen:
Birth -> Concept -> Development -> Maintenance (longest) -> Death
..and in the development phase we have one sequence of fundamental process activities; in maintenance phase we have many these sequences.


aa

System engineering: Chapter 3

Critical systems are critical ;p and it is important they are dependable.

Four principal dimensions of dependability:
a) availability - ability to deliver services when required
b) reliability - ability to deliver services as specified
c) safety - ability to operate without catastrophic failure
d) security - ability to protect itself from intrusion
we do not necessarily need all these 4 (in particular system)

System properties connected to dependability:
a) repairability - the organisation using software can repair it
b) maintainability - can be adapted easily to changing conditions
c) survivability - ability to deliver services even if being under attack or while part of the system is disabled; recovery from attack
d) error tolerance - the extent to which the system avoids and tolerate user input errors

failure - event when software does not deliver what expected
/\
||
error - state which leads to unexpected behaviour
/\
||
fault - property of software which can lead to an error

System engineering: Chapter 2

System is a purposeful collection of interrelated components that work together to achieve some objective.
a) technical computer-based systems - only hardware + software, e.g. word processor
b) socio-technical systems - include technical systems + people + processes; in organization; non deterministic; e.g. publishing system for books

Emergent(całościowe) system properties:
a) functional emergent properties - e.g. bicycle has the functional property of being a transportation device
b) non-functional emergent properties - e.g. reliability, performance, safety and security
the system success or failure is depending on these properties

Systems engineering
- activity of specifying, designing, implementing, validating, deploying and maintaining socio-technical systems; system engineers must take into account the software, hardware, people and the environment; the must think about the services the system provides, the constrains under which it must be built;
system engineering process != software development process

System engineering process includes:
a) specification
b) design
c) development
d) integration --> critical if sub-systems come from more then one supplier
e) testing

Legacy system - old socio-technical system that still provides essential business services.

Friday, February 6, 2009

Software Engineering - introduction

What is Software Engineering
"software crisis" 1968 -> new hardware, lots of new software that was much more complicated; years late; costs higher than predicted; unreliable; difficult to maintain; performed poorly; complex;
Need for technique for controlling the complexity inherent in large software systems => Software Engineering! Tada!
Nowadays: not applying SE techniques effectively => unreliable, delivered late and over budget.

1.
software = computer programs + documentation + configuration
a) generic products - stand-alone systems, e.g. for PC: word processor, database, drawing package,...;
b) customized (bespoke) products - especially for particular customer, e.g. air traffic control system;

2.
software engineering - engineering concerned with all aspects of software production, from early specification, to maintenance

3.
software process - set of activities and associated results that produce a software product.
Four fundamental process activities common to all software processes:
a) s. specification - customers ad engineers define the software to be produced and the constraints
on its operation
b) s. development (= design and implementation) - software is designed and programmed
c) s. validation - software is checked to ensure that it meets the user requirements
d) s. evolution - software modified to adapt to changing customer and market

4.
software process model - simplified description of a software process that presents one view on that process, e.g.:
a) workflow model - sequence of activities that people do
b) dataflow (activity) model - set of activities which transform data in some way; either by computers or people
c) role/action model - roles for people, what each person is responsible for
they based on one of three general models of software development:

5.
general models of software development:
a) waterfall approach - takes the process activities and represents them as separate project phases, put in order
b) iterative development - interleaves(przeplata) the process activities
c) component-based software engineering (CBSE) - developing system by integrating existing parts

Software engineering methods:
- they are structured approaches to software development which aim is to facilitate the production of high-quality software in a cost-effective way;
Method components:
a) system model descriptions - descriptions of the system models which should be developed and the notation used to define these models
b) rules - constraints which always apply to system models
c) recommendations - heuristics which characterize good design practice in this method; following these recommendations should lead to well-organized system model
d) process guidance - descriptions of the activities which may be followed to develop the system models and the organization of these activities

CASE - Computer-Aided Software Engineering - programs for supporting software process activities, e.g. requirements analysis, system modeling, debugging and testing. Also might be a code generator generating source code form the system model, with some process guidance for software engineers

Essential characteristics of a well-designed software system:
a) maintainability - can be changed
b) dependability - reliability, security, safety; not causing physical damage;p
c) efficiency - responsiveness, processing time, memory utilization,...
d) usability (acceptability) - usable for the user - appropriate user interface and adequate documentation

Key challenges for SE:
a) heterogeneity(różnorodność) - need to integrate software written in different languages, different types of support system, across the network,...
b) delivery - need for rapid software changes, shorter delivery but not by decreasing quality
c) trust - demonstrate software can be trusted
...and probably many others