Vous êtes sur la page 1sur 43

| 

Ô 






J 
J 

| 


¦    
| 
Ô 






0 Explain different types of method


0 Explore some common methods
Nature of iteration
Testing and quality points

| 


|    
¦  
| 
Ô 






0 Ñll approaches to systems (software) design


involve a System Development LifeCycle or
|¦ that involves:
1. Ñnalysis
2. Design
3. Implementation
4. Maintenance

0 Ñll SDLCs involve feedback and testing

| 


| 
Ô 






r   J 
e.g.,
Structured Systems Ñnd Design Method
(SSÑDM)

| 


r   J 
| 
Ô 





eg., SSÑDM
Î  


 
 
 


  

 

   
 

| 


r   J 
| 
Ô 





eg., SSÑDM

0 Ñssumes that:
Ñ requirements are identified at the start
Ñ the system is analysed
Ñ the system is designed
Ñ the system is written
Ñ the system is tested
Ñ the system is handed over to the client

0 So there is only 
run through the life cycle

| 


r   J 
| 
Ô 





Ñdvantages
0 Known requirements are all documented
0 Ñnalysis can cover all required areas
0 Design can be optimised as all known
requirements are included
0 Coding and testing can be carried out efficiently
as all areas to be covered are known.
0 Project management is easier as tasks required
are known ± timetables and staffing can be
planned and controlled
| 


r   J 
| 
Ô 





Disadvantages
0 What if the client thinks of important
requirements later in the project?
0 What if the client¶s requirements change during
the project?
0 What if a step in the project takes longer than
expected?
0 What if the client does not like what the
developers have produced?
0 What if the system handed over to the client
does the wrong thing?
| 


| 
Ô 






` 

 
`

| 


ë Ñ   `
| 
Ô 






0 `isk-driven process
`isk management integrated into the development process
Iterations are planned based on high priority risks
0 Use-case driven development
Use cases express requirements on the system¶s
functionality and model the business as context for the
system
Use cases are defined for the intended system and are
used as the basis of the entire development process

| 


ë Ñ   `
| 
Ô 






0 `isk-driven process
`isk management integrated into the development process
Iterations are planned based on high priority risks
0 Use-case driven development
Use cases express requirements on the system¶s
functionality and model the business as context for the
system
Use cases are defined for the intended system and are
used as the basis of the entire development process

| 


ë Ñ   `
| 
Ô 






0 Ñrchitecture-centric design
Ñrchitecture is the primary artifact to conceptualize,
construct, manage, and evolve the system
Consists of multiple, coordinated views (or models) of the
architecture

| 


`  
| 
Ô 






0 Develop Software Iteratively


Driven by early risk identification and mitigation
Each iteration results in an executable release
0 Manage `equirements
`equirements inherently dynamic across the system¶s life
0 Use Component-Based Ñrchitecture
Ñrchitectures that are resilient to change are essential

| 


`  
| 
Ô 






0 Oisually Model Software


Promotes consistency and unambiguous communication of
development information
0 Continuously Oerify Software Quality
Identify defects early, objective measure of project status
0 Control Changes to Software
Create and release a tested baseline at the end of each
iteration

| 


   
| 
Ô 






u

!  

 
"


 r 


Business Modeling
`equirements
Ñnalysis & Design
Implementation
Test & Ñssessment
Deployment

| 
r 
Change Management
Project Management
Environmental Ñnalysis
Iteration(s)
| 


| 
Ô 






" #$%J 

| 


" #$%J 
| 
Ô 






`equirements Ñcceptance Ñcceptance


Ñnalysis Test Design Test Design

System Systems Systems


Design Test Design Test Design

Ñrchitecture Integration Integration


Design Test Design Test Design

Unit Unit
Module Design
Test Design Test Design

coding

| 


| 
Ô 






" | J 

| 


" | J 
| 
Ô 






  
!     
 &
  & `isk 
&  
 
 & `isk analysis
`isk analysis

 
 analysis
`isk Operational
`eview analysis Prototype Prototype
Prototype 3
Commitment
Prototype1 2 Simulations, models, benchmarks
Partition
Software
`equirements plan Software
requirements Detailed design
Lifecycle plan Concept product
Developmental of operation design
plan `equirements Code
validation Unit
Integration
and test test
Design validation Integration
plan and test
and verification
Ñcceptance
test   & 


' Implementation
'   
Î  
      




  !"
| 


| 
Ô 






Ñ u¦!J 

|  


Ñ u¦!J 
| 
Ô 






Ñnalysis Ñnalysis Ñnalysis


Q&Ñ Q&Ñ Q&Ñ
Design Design Design
Testing Testing Testing
Coding Coding Coding

|  


Ñ u¦! r   
| 
Ô 






The Ñgile ³Manifesto´ favours:


0 Individuals and interactions over processes and tools
0 Working software over comprehensive documentation
0 Customer collaboration over contract negotiation
0 `esponding to change over following a plan.

Î  
#"$$!%  &'()*(&(
&'(  (&+'
,"
*((-.
"$$!
 " ."
| 


Ñ u¦! r   
| 
Ô 






0 In the waterfall model requirements gathering for all features


in a release leads to a design phase, which is then followed
by coding and quality assurance testing. The entire process
for a release is measured in months, if not years.
0 In contrast, the Ñgile development lifecycle is characterized
as a series of incremental µmini-releases¶. Each working
version must be complete and stable, which makes it possible
for the product release date to coincide with that of any
working version. Working versions are created at regular
intervals, called ÷  ÷ 
or
÷
, which are generally
two to four weeks long. Cycle end dates are fixed; features
that cannot be completed are moved to the next working
version.

Î  
#"$$!%  &'()*(&(
&'(  (&+'
,"
*((-.
"$$!
 " ."
| 


Ñ u¦! r   
| 
Ô 






0 In the waterfall model there is   demarcation between


roles e.g., IT experts and users, and   approaches to
interaction between the roles. Typically there are 
 (

and   (e.g., monthly), meetings with '  
 and
minutes.
0 In contrast, the Ñgile development encourages 
 
interactions between roles. In particular, ) or    
(daily of weekly)

between stakeholders that have no
agenda, or a µloose¶ agenda, and which only key actions are
recorded if there are any records at all.

Î  
#"$$!%  &'()*(&(
&'(  (&+'
,"
*((-.
"$$!
 " ."
|  


| 
Ô 






||  J 


||J

|  


||   J 
| 
Ô 





What is it?
In principle, an SSM covers:
0 examination of the problem situation
0 analysis of the ingredients (using a rich picture method)
0 coming to a root definition of significant facets of the system
of interest
0 conceptualisation and modelling
0 comparison of concept/ideal to actual
0 definition and selection of options
0 design of action programme
0 Implementation.

|  


||   J 
| 
Ô 





Problem Expression

Stating what the problem is requires situational and problem


analysis - comprehending the problem domain of interest. What
exactly the problem is will not be known until this analysis is done.
Ñ key feature of SSM is to:
ë     
  
   )

*  
 

  
   

 
 ++ 

 

     +
The analysis may involve the use of many techniques such as
checklists of things to look for, question sets, models and
frameworks of examination. It is important not to become fixed on
the use of one technique or analytical approach only. Typically
brainstorming techniques, SWOT, STEEP analysis may be used.

|  


||   J 
| 
Ô 





CÑTWOE


 - (those who more or less directly benefit or suffer e.g. customers)
from the machinations of the...
Ñ  ± Stakeholders, the players (individuals, groups, institutions and
agencies), who perform the scenes, read and interpret the script, regulate,
push and improvise. Identify and examine the role of local and institutional
actors .... who undertake the.....
"
 
- what processes, movements, conversions of X take
place? What is the nature of the production and service transformations?
What is the content and processes involved from ingredients to a sandwich,
from mixed, varied data to information, from an idea to a performance
concept or marketable product etc? What are the transformations that
generate a product or a service? How are they achieved? How well are they
performing?

|  


||   J 
| 
Ô 





CÑTWOE

r 

 or world-view - what is going on in the wider world that is
influencing and shaping the "situation" and need for the system to adapt?

 - the activity is ultimately "controlled" or paid for by owners or
trustees. Who are they and what are their imperatives? How do they
exercise their ownership power? Ñre their other stakeholders - who claim a
stake and a right to be involved i.e. as legitimate quasi-owners. Ownership
and the human activity occurs within an
!


 - the trends, events and demands of the political, legal,
economic, social, demographic, technological, ethical, competitive, natural
environments provide the context for the situation and specific problem
arena. We need to understand these.

|  


||   J 
| 
Ô 





Transformation
Checkland offers the case of an aircraft landing system where:
0 (transformation) the incoming aircraft approaches from a
height and a distance. The goal is safe landing on the runway.
0 The actors are the pilots (human and auto), the clients - the
passengers, crew, air traffic controllers, ground staff and
people living under the runway.
0 The owners include the airline owners and their agents (the
managers)
0 The environment: air lanes, traffic conditions and geographic
features, regulation of landing and take-off slots at the airport,
competition from other airports.
0 The weltanschauung may involve the rise in passenger traffic,
competition between international airports, the airport-housing
environment, high concern for safety and high technology
operations. |  


||   J 
| 
Ô 





`ich Picture

|  


||   J 
| 
Ô 





`ich Pictures
Checkland encourages the problem researchers to illustrate the
system of interest with diagrams or "rich pictures" (a diagram
"without rules"). `ich pictures show:
0 the people involved
0 the purposes they state
0 their desires and fears (use think balloons).
0 symbols to express environmental detail (activities, similar and
contentious processes, relationships (push-pull) and
transactions across organisational boundaries).
0 how and where interests agree or conflict.
`ich pictures are cartoons - funny, sad, political, ... and all at
once. The pictures of course are generated by the analysts and
hence are selective, representative of their perceptions .... and
questions.... and areas of uncertainty. | 


||   J 
| 
Ô 
The Process Oiew






Using CÑTWOE in analysis discussions and drawing a rich


picture encourages a process approach. Participants can test
assertions, assumptions, positions and the integrity of
data/information.
SSM targets existing systems. The focus is on investigation and
definition of the existing features of the organisational and how
these interact externally and internally with the system as a whole
(hence "holism") and sub-processes. Consider too the situational
and organisational "climate" (efficient, tense, wet, cold, hot,
neurotic, sloppy, democratic, sulky, joyous ...).

| 


||   J 
| 
Ô 
The Process Oiew






Ñfter problem examination and definition, SSM participants


"should" be able to "see" the organisation:
0 differently and more fully .
0 differentiate levels and sub-problems of the whole.
0 They will have researched "facts³:
positions and viewpoints at varying levels of detail.
They will have articulated many "problem" statements, some major and some
trivial.
They will have debated the evaluated assumptions about the trivial and the
major.

|  


||   J 
| 
Ô 





`oot Definition

Ñ root definition for which there is a consensus - at a


point in time - is an important outcome of the SSM
process. The analyst-researchers now need to define
the arena of concern more precisely i.e to synthesis
the "root definition". They move towards a well-
defined statement about the area of concern, its
activities and components. This may represent a
minimum that can be agreed in terms of the real
activity domain. People should be able to see what
they are agreeing to and what has been left out. It is
for internal, creative use not public dissemination«
|  


||   J 
| 
Ô 





Conceptual Modelling

With a root definition and a CÑTWOE rich picture - the analysts


can turn to an imagined, "ideal" system. Creativity and solution
generation time is here folks .... exploring:
0 the wild and fanciful
0 defining the musts and the desirables
0 evaluating and choosing
0 agreeing criteria for choosing & deciding.
Ñ "best" model may be proposed and the criteria maybe implicit
.... but be clear about what the criteria are and what has been
systematically left out of the formula!

|  


||   J 
| 
Ô 
Îive Es for Decision Criteria






0 efficacy (will it work at all?)


0 efficiency (will it work with minimum resources?)
0 effectiveness (does it contribute to the enterprise?)
0 ethics (is it sound morally?)
0 elegance (is it beautiful?)

|  


||   J 
| 
Ô 





Compare the Concept with the Current

The conceptual model should provide inspiration. Its purpose


should not be seen as criticism or threatening (these however
may arise in any human activity system) so ... simply compare the
concept with the current system. The current system exists. It
does something. The adage "if it works, don't change it" may
string to mind but.... questions now arise
0 why aren't we doing it the "ideal" way?
0 what reasons explain our current practice and behaviour?
0 how do we, at present, measure up to the ideal given the
criteria of efficiency, effectiveness, ethics and elegance
and group/political opinion?

|  


||   J 
| 
Ô 





Ñgree on Changes

0 If the current system is imperfect (why we did the analysis) -


then we have to agree on desirable changes. These
presumably may move us towards the ideal.
0 retrace our footsteps and go over our synthesis
0 re-evaluate the insight gained from each stage
0 examine how proposals may affect and be received by
stakeholders.
0 in what way will changes for which there is no
consensus/agreement result in problems?
0 The outcome is that there is some agreement - permission to
move.

|  


||   J 
| 
Ô 





Ñction/Implementation

Outcome may not be predictable. Implementation is a new human


activity. It means new compromises. If the root definition and
option analysis is still fuzzy and if there is no ownership by those
who hold the reins of power (the decision-makers) then the SSM
process could go into an infinite loop and start the whole thing
over again - rue the day!
The final outcome will not completely match the planned change.
It will be interesting to see how close they are.
Does an SSM project ever finish .... it doesn't need to as it
embodies learning - the human learning and adaptation
philosophy. There may be convergence. Issues debated early on
may dissipate. Implementation discussions may focus more on
participant confidence, ability and understanding of the enterprise.

| 


||   J 
| 
Criticisms of SSM
Ô 






0 It is not a "how to build a system guidebook". It is heuristic not


algorithmic.
0 There is no real method. But then many other, more
prescriptive "methodologies" don't work. SSM does encourage
commitment and it provides a forum to bring diverse interests
together.
0 The open endedness makes it difficult to manage. Ñn SSM
project is unlikely to be a complete success or a failure but it
should reflect a natural, evolutionary approach.

| 


||   J 
| 
Criticisms of SSM
Ô 






0 SSM can too easily ignore environmental and structural


determinants and questions of power. Organisational
members do not have equal choice and it is naive to think that
everyone can openly discuss problems, perceptions and
needs. Yet open, willing and supported discussion is more
likely to open up organisation culture - encouraging learning
and joint problem solving.
0 Openness and togetherness are implicit and explicit values of
SSM .... not easy values in a confused, conflict and
contradiction-oriented or power-centred organisation.

| 


¦    
| 
Ô 






0 Explain different types of method


0 Explore some common methods
Nature of iteration
Testing and quality points

| 



Vous aimerez peut-être aussi