SlideShare une entreprise Scribd logo
1  sur  22
Télécharger pour lire hors ligne
SPICE 2010:
                                                                    2010
                                                    10° International Conference on
                                                Software Process Improvement Capability
                                                             dEtermination

                                                            Pisa (Italy) – May 19-20, 2010




             The Need for a Legal Perspective in Software
                            Engineering Maturity Models


                                                                         Luigi Buglione
                                                                           Alain April
                                                                     Ricardo J. Rejas-Muslera

www.eng.it       SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera
Goals of the Presentation:
             Presentation
 G1. to discuss the relevance and positioning of Legal issues in
software management and ICT companies
 G2. to present current approaches for Legal Assurance
G3. to propose a Legal Management process within the ISO/IEC
15504 framework (as a new MAN.7 process)




 www.eng.it       SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera
                                                                                                     2
Agenda



• Introduction
   »   Some initial questions
   »   Legal Concerns in Software Engineering
• Related Works
   »   By ISO and related WGs
   »   By other organizations
• MAN.7: a proposal for a legal management process
   »   Background
   »   MAN.7
       -   The ‘big picture’
       -   BPs
       -   Associated WPs
• Conclusions & Prospects
• Q&A

  www.eng.it              SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera
                                                                                                             3
Introduction
             Googling about lawyers…




www.eng.it      SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera
                                                                                                   4
Introduction
             Dilbert about lawyers…




www.eng.it      SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera
                                                                                                   5
Introduction
                   Some initial questions…



• Q: Is litigation in the software industry increasing or
decreasing?


         • Q: Does your company use Open Source Software? Which
         kind of licences are you dealing with?


• Q: Are you compliant with Sarbanes-Oxley requirements?



          • Q: How much does it cost the (eventual) non-compliance to
          legal requirements?



  www.eng.it          SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera
                                                                                                         6
Introduction
             Some legal Concerns in Software Engineering




www.eng.it      SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera
                                                                                                   7
Agenda



• Introduction
   »   Some initial questions
   »   Legal Concerns in Software Engineering
• Related Works
   »   By ISO and related WGs
   »   By other organizations
• MAN.7: a proposal for a legal management process
   »   Links with ISO/IEC 12207
   »   MAN.7
       -   The ‘big picture’
       -   BPs
       -   Associated WPs
• Conclusions & Prospects
• Q&A

  www.eng.it              SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera
                                                                                                             8
Related Works
                    By ISO and its related WGs


• ISO/IEC 12207 & 15288
     Not included specific processes or practices to manage legal issues

• ISO/IEC 15504 (PRM)
     A specific process group on Acquisition practices (ACQ.x)
     5 processes, recently incorporated
          ACQ.1 (Acq. Preparation); ACQ.2 (Supplier Selection); ACQ.3
         (Contract Agreement); ACQ.4 (Supplier Monitoring); ACQ.5 (Customer
         Acceptance)

• AutomotiveSPICE
     ACQ.13 is about Legal Assurance (not Management)


…but with few or no specific indications for legal and contractual issues



  www.eng.it           SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera
                                                                                                          9
Related Works
                    By Other Organizations

• CMMI-ACQ
     5 process areas between ML2 and ML3
          ML2  AM (Agreement Mgmt); ARD (Acq. Req. Development); ML3  ATM
         (Acq. Tech. Mgmt); AVAL (Acq. Validation); AVER (Acq. Verification)
• Risk & Contract Management MM
     INCOSE RMMM (Risk Management Maturity Model)
     RMM (Enterprise Risk Management)
     IACMM CMM (Contract Management)
• Project Mgmt MM
     OGC’s P3M3
     OGC’s P2MM (Prince2 Maturity Model)
     PMI OPM3
• Other MMs
     S3M (Software Maintenance Maturity Model)
    …
…but with few or no specific indications for legal and contractual issues
  www.eng.it           SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera
                                                                                                          10
Agenda



• Introduction
   »   Some initial questions
   »   Legal Concerns in Software Engineering
• Related Works
   »   By ISO and related WGs
   »   By other organizations
• MAN.7: a proposal for a legal management process
   »   Links with ISO/IEC 12207
   »   MAN.7
       -   The ‘big picture’
       -   BPs
       -   Associated WPs
• Conclusions & Prospects
• Q&A

  www.eng.it              SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera
                                                                                                             11
MAN.7
                    Background

• What different from ACQ.13?
     Process scope  from due diligence to legal management
     Location of the process within the model  MAN process group, not ACQ
     Legal activities execution steps  activities to be run during the whole
    product lifecycle, not only at the beginning, when supplier-customer
    interactions are executed

• ISO/IEC 12207 - clause 6.4.1.3.2.3
     ‘The project shall define a representative set of activity sequences to
    identify all required services that correspond to anticipated operational and
    support scenarios and environments’.
• A first proposal for the CMMI architecture
     A new proposal for a ‘Support’ process
     Suggested to be placed at ML2 (staged), but used in the ‘continuous’
    representation



  www.eng.it           SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera
                                                                                                          12
MAN.7
             The ‘big picture’




                                                                                                   MAN.7 Legal
                                                                                                   Management




www.eng.it      SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera
                                                                                                                 13
MAN.7
                             Name, Purpose, Outcomes

    Process ID      MAN.7

  Process Name      Legal Management

 Process Purpose The purpose of the Legal Management process is to deal with the possible legal issues arising in the
                 project lifetime, establish a protection strategy, measuring the legal exposure and conducting
                 appropriate actions in order to prevent or avoid litigations or legal penalties.
Process Outcomes As a result of a successful implementation of the Legal Management process:
                    1)   Legal assurance plan is established.
                     2) Software product is conform with in force law, especially data protection law, industrial property
                    law, antitrust law, and e-business regulations, if a website is developed.
                    3)   Software product is respectful with Intellectual Property of others companies.
                     4) Software product is properly developed, in terms of staff involved, staff contracts and IP
                    agreements which protect it against staff claims. Risk of reclamation is assessed.
                     5) Software Intellectual property is registered and ready to be opposed against eventual
                    infringements.
                     6) Software development contract is developed. Object of the software development contract is
                    clearly-defined by means of the requirement document reinforced by means of the requirement
                    document's signature.
                     7) Software is protected against illicit copies or piracy, the introduction of elements as innocuous
                    code, bestow a relevant evidence against illicit copies upon the developer.
                    8)   Software commercialization is regulated by means of licenses or default contracts.




   www.eng.it                     SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera
                                                                                                                             14
MAN.7
                           BPs – Base Practices (1/2)
BP.1         Define the objectives for the Legal Management process. Identify and define the objectives for a
             legal management process aligned with the organizational goals and policies. [Outcome: 1, 2]
             Sub-practices:
              Establish the legal assurance scope
              Define the legal assurance measures according with the software specifications


BP.2         Reduce or minimize risks for the Legal Management process. Provide an adequate intellectual
             property protection by risk management. [Outcome: 3,4]
             Sub-practices:
              State available legal assurance activities;
              Perform a descriptive analysis of previously defined activities;
              Set temporally the legal assurance measures according with the product life cycle

BP.3         Legal exposure at the implementation phase. After determining the scope and list of possible project
             legal threats, each must be assessed by the individuals responsible of such issues and obligations, verifying
             the presence of mandatory clauses in contracts and regulations. [Outcome: 5, 6,7]
             Sub-practices:
              Establish the rights and obligations by responsible personnel
              Establish the rights and obligations due by internal personnel
              Verify the presence of mandatory legal clauses on the software development contracts 

BP.4         Legal exposure at the requirements phase. An important step aims at defining of the scope of
             possible legal risks during the project life cycle. Moving from the project requirements, it is requested to
             find all possible explicit and implicit legal threats the project could express. [Outcome: 2, 3, 6]
             Sub-practices:
              Approve and sign the requirements;
              Verify the completeness and consistency of the requirement traceability document;
              Approve and sign the prototype document limiting their use


www.eng.it                       SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera
                                                                                                                            15
MAN.7
                           BPs – Base Practices (2/2)
BP.5         Legal exposure at the architectural and detailed design phases. As a second step, the verification
             of collected elements against the applicable software licenses after the SRS is completed and before the
             Coding phase starts. This task represent an important step for quantifying the legal risk, if it would take
             place in the near future and therefore impacting on the project budget. [Outcome: 6]
             Sub-practices:
              Verify and ensure the compliance to all the applicable software licenses;
              Verify and ensure the performance of personnel data protection regulation

BP.6         Legal exposure at the construction phase. During the coding phase, it is requested an analysis of the
             source code produced by the organization, paying attention to the elements produced/incorporated within
             the software solution, as meta-tags or other DRM-related issues. [Outcome: 2, 6, 7]
             Sub-practices:
              Ensure intellectual property rights for the product
              Verify the legal conformance of incorporated web elements

BP.7         Legal exposure at the integration and qualification testing phase. During the Test and Release
             phase, the accompanying actions requested on the legal side will face the duties for an eventual
             registration of the software product, according to kind of license established between the parties as well as
             the licensing documentation to be provided to the customer at the release. [Outcome: 5, 8]
             Sub-practices:
              Ensure the software improvements intellectual property rights : application form copyrights, patents, notarial deposit
              Write the licensing document and a template for the acceptance of the delivered product

BP.8         Legal exposure at the Maintenance phase. the maintenance phase will require an update on a
             regularly basis of the legal assurance on the current contracts. [Outcome: 8]
             Sub-practices:
              Software maintenance is regulated;
              Proper SLA terms are established.
              Software intellectual property rights are assured and improvements are developed (new functionality or adaptation of the
             existent).

www.eng.it                       SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera
                                                                                                                                          16
MAN.7
                                 WPs – Associated Work Products


                            Inputs                                                                       Outputs
         Project Plan and Life Cycle model (outcome 1 )                             Legal Assurance Plan (outcome 1)
Human resource management plan and supplier selection (outcome 4) Contracts and agreements with responsible, internal personnel and staff
                                                                                  working for subcontractors (outcome 4)
 Agreements with the client and high level's software specifications       Contract Software Development Sketch (outcome 6)
                            (outcome 6)
             Requirement specification (outcome 6)                            Signed Requirement Specification (outcome 6)

           Signed Requirement Specification (outcome 6)                    Development contract adding Signed Requirement Specification
                                                                                                     (outcome 6)
                   Prototype design (outcome 6)                                           Prototype Document (outcome 6)

           Licenses used in the development (outcome 3)                            Obligations and liabilities Licenses report (outcome 3)

            Software functionality document (outcome 6)                            Obligations on data protection law report (outcome 2)

      Low level software design and source code (outcome 7)                   Low level software design including stenography (outcome 7)

    Graphical design and Low and high level design (outcome 7)                                 Legal Web Report (outcome 2)

  Requirement specification, Low and high level design (outcome 7)         Applications form to register Intellectual Property rights (copyrights,
                                                                                       patents, register into notary...) (outcome 5)
               Commercialization policy (outcome 8)                       Licenses and default contracts to the software commercialization
                                                                                                       (outcome 8)
           Installation and maintenance plan (outcome 8)                                    Maintenance contract (outcome 8)

                 Maintenance strategy (outcome 8)                                                 SLA contract (outcome 8)

    Improvement software design and source code (outcome 8)                                                    ----




  www.eng.it                           SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera
                                                                                                                                                     17
Agenda



• Introduction
   »   Some initial questions
   »   Legal Concerns in Software Engineering
• Related Works
   »   By ISO and related WGs
   »   By other organizations
• MAN.7: a proposal for a legal management process
   »   Links with ISO/IEC 12207
   »   MAN.7
       -   The ‘big picture’
       -   BPs
       -   Associated WPs
• Conclusions & Prospects
• Q&A

  www.eng.it              SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera
                                                                                                             18
Conclusions & Prospects


• State-of-the-art
     A plenty of situation also in ICT need a legal support
     Most known process and maturity models partly deal with legal issues,
    mostly from an ‘assurance’ than a ‘proactive’ perspective
• MAN.7: a proposal
     A new process on Legal Management, according to ISO/IEC 15504 process
    architecture (after having done it also with the CMMI language)
     Included in the MAN group (not in the ACQ)
• Next actions
     Refine and reinforce MAN.7 by a V&V activity on a series of case studies
     Try to catch the most general and comprehensive definitions also for WPs,
    looking at a larger IT audience




  www.eng.it          SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera
                                                                                                         19
Some quotings…



                   No law or ordinance is mightier than understanding
                                                               (Plato, philosopher)



       All litigation is inherently a clumsy, time-consuming business
                                       (Warren E. Burger, chief justice of UU.SS.)



Maturity is achieved when a person postpones immediate pleasures for
                         long-term values.
                        (Joshua Loth Liebman, American rabbi and writer)




  www.eng.it           SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera
                                                                                                          20
Q&A




      Thanks for your attention!
    Grazie per la vostra attenzione!
www.eng.it    SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera
                                                                                                 21
Luigi Buglione                   Alain April                                 Ricardo Rejas-Muslera
Engineering.IT/ETS                      ETS                                         Univ. de Alcala’
luigi.buglione@eng.it          alain.april@etsmtl.ca                              ricardo.rejas@uah.es




www.eng.it          SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera

Contenu connexe

Plus de Luigi Buglione

Do we really re-use our knowledge (or not)?
Do we really re-use our knowledge (or not)?Do we really re-use our knowledge (or not)?
Do we really re-use our knowledge (or not)?Luigi Buglione
 
Balanced Measurement Sets: Criteria for Improving Project Management Practices
Balanced Measurement Sets: Criteria for Improving  Project Management PracticesBalanced Measurement Sets: Criteria for Improving  Project Management Practices
Balanced Measurement Sets: Criteria for Improving Project Management PracticesLuigi Buglione
 
PIF or SNAP? That's the Question! Or maybe it's not? - A panel
PIF or SNAP? That's the Question! Or maybe it's not? - A panelPIF or SNAP? That's the Question! Or maybe it's not? - A panel
PIF or SNAP? That's the Question! Or maybe it's not? - A panelLuigi Buglione
 
Software Sustainability: a Broader Perspective
Software Sustainability: a Broader PerspectiveSoftware Sustainability: a Broader Perspective
Software Sustainability: a Broader PerspectiveLuigi Buglione
 
An ISO/IEC 33000-compliant Measurement Framework for Software Process Sustain...
An ISO/IEC 33000-compliant Measurement Framework for Software Process Sustain...An ISO/IEC 33000-compliant Measurement Framework for Software Process Sustain...
An ISO/IEC 33000-compliant Measurement Framework for Software Process Sustain...Luigi Buglione
 
Measurement Process: Improving the ISO 15939 Standard
Measurement Process: Improving the ISO 15939 StandardMeasurement Process: Improving the ISO 15939 Standard
Measurement Process: Improving the ISO 15939 StandardLuigi Buglione
 
Sizing The Entire Development Process
Sizing The Entire Development ProcessSizing The Entire Development Process
Sizing The Entire Development ProcessLuigi Buglione
 
The LEGO Strategy: Guidelines for a Profitable Deployment
The LEGO Strategy: Guidelines for a Profitable DeploymentThe LEGO Strategy: Guidelines for a Profitable Deployment
The LEGO Strategy: Guidelines for a Profitable DeploymentLuigi Buglione
 
ICEBERG: a different look at Software Project Management
ICEBERG: a different look at Software Project ManagementICEBERG: a different look at Software Project Management
ICEBERG: a different look at Software Project ManagementLuigi Buglione
 
Improving Measurement Plans from multiple dimensions: Exercising with Balanci...
Improving Measurement Plans from multiple dimensions: Exercising with Balanci...Improving Measurement Plans from multiple dimensions: Exercising with Balanci...
Improving Measurement Plans from multiple dimensions: Exercising with Balanci...Luigi Buglione
 
Improving the User Story Agile Technique Using the INVEST Criteria
Improving the User Story Agile Technique Using the  INVEST CriteriaImproving the User Story Agile Technique Using the  INVEST Criteria
Improving the User Story Agile Technique Using the INVEST CriteriaLuigi Buglione
 
Leveraging Reuse-related Maturity Issues for Achieving Higher Maturity & Capa...
Leveraging Reuse-related Maturity Issues for Achieving Higher Maturity & Capa...Leveraging Reuse-related Maturity Issues for Achieving Higher Maturity & Capa...
Leveraging Reuse-related Maturity Issues for Achieving Higher Maturity & Capa...Luigi Buglione
 
Derivation of Green Metrics for Software
Derivation of Green Metrics for SoftwareDerivation of Green Metrics for Software
Derivation of Green Metrics for SoftwareLuigi Buglione
 
Software Architects’ Experiences of Quality Requirements: What we Know and ...
Software Architects’ Experiences  of Quality Requirements:  What we Know and ...Software Architects’ Experiences  of Quality Requirements:  What we Know and ...
Software Architects’ Experiences of Quality Requirements: What we Know and ...Luigi Buglione
 
La Resilienza e i Modelli di Maturità
La Resilienza e i Modelli di MaturitàLa Resilienza e i Modelli di Maturità
La Resilienza e i Modelli di MaturitàLuigi Buglione
 
Mapping Automotive SPICE: Achieving Higher Maturity & Capability Levels
Mapping Automotive SPICE: Achieving Higher Maturity & Capability LevelsMapping Automotive SPICE: Achieving Higher Maturity & Capability Levels
Mapping Automotive SPICE: Achieving Higher Maturity & Capability LevelsLuigi Buglione
 
The GP 2.8 Game - – Deploying a Balanced Measurement Plan by the ‘Play’n’Lear...
The GP 2.8 Game - – Deploying a Balanced Measurement Plan by the ‘Play’n’Lear...The GP 2.8 Game - – Deploying a Balanced Measurement Plan by the ‘Play’n’Lear...
The GP 2.8 Game - – Deploying a Balanced Measurement Plan by the ‘Play’n’Lear...Luigi Buglione
 
Tailoring Software Process Capability/Maturity Models for Telemedicine Systems
Tailoring Software Process Capability/Maturity  Models for Telemedicine SystemsTailoring Software Process Capability/Maturity  Models for Telemedicine Systems
Tailoring Software Process Capability/Maturity Models for Telemedicine SystemsLuigi Buglione
 
Measuring Software Sustainability from a Process-Centric Perspective
Measuring Software Sustainability from a Process-Centric PerspectiveMeasuring Software Sustainability from a Process-Centric Perspective
Measuring Software Sustainability from a Process-Centric PerspectiveLuigi Buglione
 
MASP (Metrics in Automotive Software Projects) - Purpose, Scope & Results
MASP (Metrics in Automotive Software Projects) - Purpose, Scope & ResultsMASP (Metrics in Automotive Software Projects) - Purpose, Scope & Results
MASP (Metrics in Automotive Software Projects) - Purpose, Scope & ResultsLuigi Buglione
 

Plus de Luigi Buglione (20)

Do we really re-use our knowledge (or not)?
Do we really re-use our knowledge (or not)?Do we really re-use our knowledge (or not)?
Do we really re-use our knowledge (or not)?
 
Balanced Measurement Sets: Criteria for Improving Project Management Practices
Balanced Measurement Sets: Criteria for Improving  Project Management PracticesBalanced Measurement Sets: Criteria for Improving  Project Management Practices
Balanced Measurement Sets: Criteria for Improving Project Management Practices
 
PIF or SNAP? That's the Question! Or maybe it's not? - A panel
PIF or SNAP? That's the Question! Or maybe it's not? - A panelPIF or SNAP? That's the Question! Or maybe it's not? - A panel
PIF or SNAP? That's the Question! Or maybe it's not? - A panel
 
Software Sustainability: a Broader Perspective
Software Sustainability: a Broader PerspectiveSoftware Sustainability: a Broader Perspective
Software Sustainability: a Broader Perspective
 
An ISO/IEC 33000-compliant Measurement Framework for Software Process Sustain...
An ISO/IEC 33000-compliant Measurement Framework for Software Process Sustain...An ISO/IEC 33000-compliant Measurement Framework for Software Process Sustain...
An ISO/IEC 33000-compliant Measurement Framework for Software Process Sustain...
 
Measurement Process: Improving the ISO 15939 Standard
Measurement Process: Improving the ISO 15939 StandardMeasurement Process: Improving the ISO 15939 Standard
Measurement Process: Improving the ISO 15939 Standard
 
Sizing The Entire Development Process
Sizing The Entire Development ProcessSizing The Entire Development Process
Sizing The Entire Development Process
 
The LEGO Strategy: Guidelines for a Profitable Deployment
The LEGO Strategy: Guidelines for a Profitable DeploymentThe LEGO Strategy: Guidelines for a Profitable Deployment
The LEGO Strategy: Guidelines for a Profitable Deployment
 
ICEBERG: a different look at Software Project Management
ICEBERG: a different look at Software Project ManagementICEBERG: a different look at Software Project Management
ICEBERG: a different look at Software Project Management
 
Improving Measurement Plans from multiple dimensions: Exercising with Balanci...
Improving Measurement Plans from multiple dimensions: Exercising with Balanci...Improving Measurement Plans from multiple dimensions: Exercising with Balanci...
Improving Measurement Plans from multiple dimensions: Exercising with Balanci...
 
Improving the User Story Agile Technique Using the INVEST Criteria
Improving the User Story Agile Technique Using the  INVEST CriteriaImproving the User Story Agile Technique Using the  INVEST Criteria
Improving the User Story Agile Technique Using the INVEST Criteria
 
Leveraging Reuse-related Maturity Issues for Achieving Higher Maturity & Capa...
Leveraging Reuse-related Maturity Issues for Achieving Higher Maturity & Capa...Leveraging Reuse-related Maturity Issues for Achieving Higher Maturity & Capa...
Leveraging Reuse-related Maturity Issues for Achieving Higher Maturity & Capa...
 
Derivation of Green Metrics for Software
Derivation of Green Metrics for SoftwareDerivation of Green Metrics for Software
Derivation of Green Metrics for Software
 
Software Architects’ Experiences of Quality Requirements: What we Know and ...
Software Architects’ Experiences  of Quality Requirements:  What we Know and ...Software Architects’ Experiences  of Quality Requirements:  What we Know and ...
Software Architects’ Experiences of Quality Requirements: What we Know and ...
 
La Resilienza e i Modelli di Maturità
La Resilienza e i Modelli di MaturitàLa Resilienza e i Modelli di Maturità
La Resilienza e i Modelli di Maturità
 
Mapping Automotive SPICE: Achieving Higher Maturity & Capability Levels
Mapping Automotive SPICE: Achieving Higher Maturity & Capability LevelsMapping Automotive SPICE: Achieving Higher Maturity & Capability Levels
Mapping Automotive SPICE: Achieving Higher Maturity & Capability Levels
 
The GP 2.8 Game - – Deploying a Balanced Measurement Plan by the ‘Play’n’Lear...
The GP 2.8 Game - – Deploying a Balanced Measurement Plan by the ‘Play’n’Lear...The GP 2.8 Game - – Deploying a Balanced Measurement Plan by the ‘Play’n’Lear...
The GP 2.8 Game - – Deploying a Balanced Measurement Plan by the ‘Play’n’Lear...
 
Tailoring Software Process Capability/Maturity Models for Telemedicine Systems
Tailoring Software Process Capability/Maturity  Models for Telemedicine SystemsTailoring Software Process Capability/Maturity  Models for Telemedicine Systems
Tailoring Software Process Capability/Maturity Models for Telemedicine Systems
 
Measuring Software Sustainability from a Process-Centric Perspective
Measuring Software Sustainability from a Process-Centric PerspectiveMeasuring Software Sustainability from a Process-Centric Perspective
Measuring Software Sustainability from a Process-Centric Perspective
 
MASP (Metrics in Automotive Software Projects) - Purpose, Scope & Results
MASP (Metrics in Automotive Software Projects) - Purpose, Scope & ResultsMASP (Metrics in Automotive Software Projects) - Purpose, Scope & Results
MASP (Metrics in Automotive Software Projects) - Purpose, Scope & Results
 

The Need for a Legal Perspective in Software Engineering Maturity Models

  • 1. SPICE 2010: 2010 10° International Conference on Software Process Improvement Capability dEtermination Pisa (Italy) – May 19-20, 2010 The Need for a Legal Perspective in Software Engineering Maturity Models Luigi Buglione Alain April Ricardo J. Rejas-Muslera www.eng.it SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera
  • 2. Goals of the Presentation: Presentation  G1. to discuss the relevance and positioning of Legal issues in software management and ICT companies  G2. to present current approaches for Legal Assurance G3. to propose a Legal Management process within the ISO/IEC 15504 framework (as a new MAN.7 process) www.eng.it SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera 2
  • 3. Agenda • Introduction » Some initial questions » Legal Concerns in Software Engineering • Related Works » By ISO and related WGs » By other organizations • MAN.7: a proposal for a legal management process » Background » MAN.7 - The ‘big picture’ - BPs - Associated WPs • Conclusions & Prospects • Q&A www.eng.it SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera 3
  • 4. Introduction Googling about lawyers… www.eng.it SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera 4
  • 5. Introduction Dilbert about lawyers… www.eng.it SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera 5
  • 6. Introduction Some initial questions… • Q: Is litigation in the software industry increasing or decreasing? • Q: Does your company use Open Source Software? Which kind of licences are you dealing with? • Q: Are you compliant with Sarbanes-Oxley requirements? • Q: How much does it cost the (eventual) non-compliance to legal requirements? www.eng.it SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera 6
  • 7. Introduction Some legal Concerns in Software Engineering www.eng.it SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera 7
  • 8. Agenda • Introduction » Some initial questions » Legal Concerns in Software Engineering • Related Works » By ISO and related WGs » By other organizations • MAN.7: a proposal for a legal management process » Links with ISO/IEC 12207 » MAN.7 - The ‘big picture’ - BPs - Associated WPs • Conclusions & Prospects • Q&A www.eng.it SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera 8
  • 9. Related Works By ISO and its related WGs • ISO/IEC 12207 & 15288  Not included specific processes or practices to manage legal issues • ISO/IEC 15504 (PRM)  A specific process group on Acquisition practices (ACQ.x)  5 processes, recently incorporated  ACQ.1 (Acq. Preparation); ACQ.2 (Supplier Selection); ACQ.3 (Contract Agreement); ACQ.4 (Supplier Monitoring); ACQ.5 (Customer Acceptance) • AutomotiveSPICE  ACQ.13 is about Legal Assurance (not Management) …but with few or no specific indications for legal and contractual issues www.eng.it SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera 9
  • 10. Related Works By Other Organizations • CMMI-ACQ  5 process areas between ML2 and ML3  ML2  AM (Agreement Mgmt); ARD (Acq. Req. Development); ML3  ATM (Acq. Tech. Mgmt); AVAL (Acq. Validation); AVER (Acq. Verification) • Risk & Contract Management MM  INCOSE RMMM (Risk Management Maturity Model)  RMM (Enterprise Risk Management)  IACMM CMM (Contract Management) • Project Mgmt MM  OGC’s P3M3  OGC’s P2MM (Prince2 Maturity Model)  PMI OPM3 • Other MMs  S3M (Software Maintenance Maturity Model) … …but with few or no specific indications for legal and contractual issues www.eng.it SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera 10
  • 11. Agenda • Introduction » Some initial questions » Legal Concerns in Software Engineering • Related Works » By ISO and related WGs » By other organizations • MAN.7: a proposal for a legal management process » Links with ISO/IEC 12207 » MAN.7 - The ‘big picture’ - BPs - Associated WPs • Conclusions & Prospects • Q&A www.eng.it SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera 11
  • 12. MAN.7 Background • What different from ACQ.13?  Process scope  from due diligence to legal management  Location of the process within the model  MAN process group, not ACQ  Legal activities execution steps  activities to be run during the whole product lifecycle, not only at the beginning, when supplier-customer interactions are executed • ISO/IEC 12207 - clause 6.4.1.3.2.3  ‘The project shall define a representative set of activity sequences to identify all required services that correspond to anticipated operational and support scenarios and environments’. • A first proposal for the CMMI architecture  A new proposal for a ‘Support’ process  Suggested to be placed at ML2 (staged), but used in the ‘continuous’ representation www.eng.it SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera 12
  • 13. MAN.7 The ‘big picture’ MAN.7 Legal Management www.eng.it SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera 13
  • 14. MAN.7 Name, Purpose, Outcomes Process ID MAN.7 Process Name Legal Management Process Purpose The purpose of the Legal Management process is to deal with the possible legal issues arising in the project lifetime, establish a protection strategy, measuring the legal exposure and conducting appropriate actions in order to prevent or avoid litigations or legal penalties. Process Outcomes As a result of a successful implementation of the Legal Management process: 1) Legal assurance plan is established. 2) Software product is conform with in force law, especially data protection law, industrial property law, antitrust law, and e-business regulations, if a website is developed. 3) Software product is respectful with Intellectual Property of others companies. 4) Software product is properly developed, in terms of staff involved, staff contracts and IP agreements which protect it against staff claims. Risk of reclamation is assessed. 5) Software Intellectual property is registered and ready to be opposed against eventual infringements. 6) Software development contract is developed. Object of the software development contract is clearly-defined by means of the requirement document reinforced by means of the requirement document's signature. 7) Software is protected against illicit copies or piracy, the introduction of elements as innocuous code, bestow a relevant evidence against illicit copies upon the developer. 8) Software commercialization is regulated by means of licenses or default contracts. www.eng.it SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera 14
  • 15. MAN.7 BPs – Base Practices (1/2) BP.1 Define the objectives for the Legal Management process. Identify and define the objectives for a legal management process aligned with the organizational goals and policies. [Outcome: 1, 2] Sub-practices:  Establish the legal assurance scope  Define the legal assurance measures according with the software specifications BP.2 Reduce or minimize risks for the Legal Management process. Provide an adequate intellectual property protection by risk management. [Outcome: 3,4] Sub-practices:  State available legal assurance activities;  Perform a descriptive analysis of previously defined activities;  Set temporally the legal assurance measures according with the product life cycle BP.3 Legal exposure at the implementation phase. After determining the scope and list of possible project legal threats, each must be assessed by the individuals responsible of such issues and obligations, verifying the presence of mandatory clauses in contracts and regulations. [Outcome: 5, 6,7] Sub-practices:  Establish the rights and obligations by responsible personnel  Establish the rights and obligations due by internal personnel  Verify the presence of mandatory legal clauses on the software development contracts  BP.4 Legal exposure at the requirements phase. An important step aims at defining of the scope of possible legal risks during the project life cycle. Moving from the project requirements, it is requested to find all possible explicit and implicit legal threats the project could express. [Outcome: 2, 3, 6] Sub-practices:  Approve and sign the requirements;  Verify the completeness and consistency of the requirement traceability document;  Approve and sign the prototype document limiting their use www.eng.it SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera 15
  • 16. MAN.7 BPs – Base Practices (2/2) BP.5 Legal exposure at the architectural and detailed design phases. As a second step, the verification of collected elements against the applicable software licenses after the SRS is completed and before the Coding phase starts. This task represent an important step for quantifying the legal risk, if it would take place in the near future and therefore impacting on the project budget. [Outcome: 6] Sub-practices:  Verify and ensure the compliance to all the applicable software licenses;  Verify and ensure the performance of personnel data protection regulation BP.6 Legal exposure at the construction phase. During the coding phase, it is requested an analysis of the source code produced by the organization, paying attention to the elements produced/incorporated within the software solution, as meta-tags or other DRM-related issues. [Outcome: 2, 6, 7] Sub-practices:  Ensure intellectual property rights for the product  Verify the legal conformance of incorporated web elements BP.7 Legal exposure at the integration and qualification testing phase. During the Test and Release phase, the accompanying actions requested on the legal side will face the duties for an eventual registration of the software product, according to kind of license established between the parties as well as the licensing documentation to be provided to the customer at the release. [Outcome: 5, 8] Sub-practices:  Ensure the software improvements intellectual property rights : application form copyrights, patents, notarial deposit  Write the licensing document and a template for the acceptance of the delivered product BP.8 Legal exposure at the Maintenance phase. the maintenance phase will require an update on a regularly basis of the legal assurance on the current contracts. [Outcome: 8] Sub-practices:  Software maintenance is regulated;  Proper SLA terms are established.  Software intellectual property rights are assured and improvements are developed (new functionality or adaptation of the existent). www.eng.it SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera 16
  • 17. MAN.7 WPs – Associated Work Products Inputs Outputs Project Plan and Life Cycle model (outcome 1 ) Legal Assurance Plan (outcome 1) Human resource management plan and supplier selection (outcome 4) Contracts and agreements with responsible, internal personnel and staff working for subcontractors (outcome 4) Agreements with the client and high level's software specifications Contract Software Development Sketch (outcome 6) (outcome 6) Requirement specification (outcome 6) Signed Requirement Specification (outcome 6) Signed Requirement Specification (outcome 6) Development contract adding Signed Requirement Specification (outcome 6) Prototype design (outcome 6) Prototype Document (outcome 6) Licenses used in the development (outcome 3) Obligations and liabilities Licenses report (outcome 3) Software functionality document (outcome 6) Obligations on data protection law report (outcome 2) Low level software design and source code (outcome 7) Low level software design including stenography (outcome 7) Graphical design and Low and high level design (outcome 7) Legal Web Report (outcome 2) Requirement specification, Low and high level design (outcome 7) Applications form to register Intellectual Property rights (copyrights, patents, register into notary...) (outcome 5) Commercialization policy (outcome 8) Licenses and default contracts to the software commercialization (outcome 8) Installation and maintenance plan (outcome 8) Maintenance contract (outcome 8) Maintenance strategy (outcome 8) SLA contract (outcome 8) Improvement software design and source code (outcome 8) ---- www.eng.it SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera 17
  • 18. Agenda • Introduction » Some initial questions » Legal Concerns in Software Engineering • Related Works » By ISO and related WGs » By other organizations • MAN.7: a proposal for a legal management process » Links with ISO/IEC 12207 » MAN.7 - The ‘big picture’ - BPs - Associated WPs • Conclusions & Prospects • Q&A www.eng.it SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera 18
  • 19. Conclusions & Prospects • State-of-the-art  A plenty of situation also in ICT need a legal support  Most known process and maturity models partly deal with legal issues, mostly from an ‘assurance’ than a ‘proactive’ perspective • MAN.7: a proposal  A new process on Legal Management, according to ISO/IEC 15504 process architecture (after having done it also with the CMMI language)  Included in the MAN group (not in the ACQ) • Next actions  Refine and reinforce MAN.7 by a V&V activity on a series of case studies  Try to catch the most general and comprehensive definitions also for WPs, looking at a larger IT audience www.eng.it SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera 19
  • 20. Some quotings… No law or ordinance is mightier than understanding (Plato, philosopher) All litigation is inherently a clumsy, time-consuming business (Warren E. Burger, chief justice of UU.SS.) Maturity is achieved when a person postpones immediate pleasures for long-term values. (Joshua Loth Liebman, American rabbi and writer) www.eng.it SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera 20
  • 21. Q&A Thanks for your attention! Grazie per la vostra attenzione! www.eng.it SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera 21
  • 22. Luigi Buglione Alain April Ricardo Rejas-Muslera Engineering.IT/ETS ETS Univ. de Alcala’ luigi.buglione@eng.it alain.april@etsmtl.ca ricardo.rejas@uah.es www.eng.it SPICE 2010, Pisa (Italy), May 19, 2010 © L.Buglione, A.April, R.J. Rejas-Muslera