goal driven iterative software project management - lirias

GOAL DRIVEN ITERATIVE SOFTWARE PROJECTMANAGEMENT

Yves Wautelet1 and Manuel Kolp21Faculteit Economie en Management, Hogeschool-Universiteit Brussel, Brussels, Belgium

2Louvain School of Management, Dept of Operation and Information Systems, Universite catholique de LouvainLouvain-la-Neuve, Belgium

[email protected], [email protected]

Keywords: Iterative development, Agent-oriented software engineering, i* modeling, Software project management.

Abstract: Iterative development has gained popularity in the software industry notably in the development of enterpriseapplications where requirements and needs are difficult to express for the users and business processes difficultto understand by analysts. Such a software development lifecycle is nevertheless often used in anad-hocmanner. Even when templates such as the Unified Process are furnished, poor documentation is providedon how to breakdown the project into manageable units and to plan their development. This paper defines atemplate for agent-oriented iterative development as wellas a software project management framework to planthe project iterations. The agent paradigm is used at analysis level with actors’ goals considered as piecingelements, an iterative template is proposed for planning purpose. High-level risk and quality issues focus onprioritizing the project goals so that each element’s “criticality” can be evaluated and a model-driven scheduleof the overall software project can be set up. The software process is illustrated with the development of aproduction planning system for a steel industry.

1 INTRODUCTION

Due to benefits and advantages such as efficient soft-ware project management, continuous organizationalmodeling and requirements acquisition, early im-plementation, continuous testing and modularity, it-erative development is more and more adopted bysoftware engineering professionals especially throughmethodologies such as the Unified Process (Kruchten,2003). The idea governing the iterative approach isto decompose a software development process intoa series of manageable entities avoiding to face as awhole every aspect of the project. Moreover, vari-able and non measurable effort is spent on each ofthe engineering disciplines during each of the iter-ations for fast prototyping and early testing. Obvi-ously, the most risky issues i.e., the most difficult tobe expressed by the users, understood by the analystsor those addressing the most sensitive issues (suchas security, flexibility, adaptability,...) receive highestpriority. Consequently, these ”critical” questions aredealt with first so that the development team receivesfeedback from users and from the whole system en-vironment early on. This improves the probability ofadequately meeting user requirements and getting an

adequate adoption of the system into its environment.Most software methodologies based on the agent

paradigm use a pure waterfall software developmentlife cycle (SDLC) or advise their users to repeat stages”iteratively” during the project in anad-hocway. Onemain reason resides in the fact that no theoreticalframework to support this way of proceeding has everbeen defined and published. We believe that iterativedevelopment requires a formal or semi-formal man-agerial framework to support dynamic requirementsand risk-driven development planning so that we re-quire an adequate way of breaking the software prob-lem into independent manageable entities and then toprioritize them to plan their development and evaluatetheir achievement.

Tropos (Castro et al., 2002) is an agent-orientedrequirement-driven methodology that uses the i* (i-star) modeling framework (Yu, 1995; Yu, 2011) dur-ing the analysis stage; i* defines advanced organiza-tional modeling features and semantics in the formof agents, goals, tasks and resources. This allowsto partition a software problem on the basis of theagent paradigm, the main reason we have chosen toextend Tropos with an iterative template and use thei* goals as fundamental entities to decompose the

44

problem into several aspects. Let us note that theresearch is actually generic enough to be adopted toextend other agent-oriented software methodologies.Iterative planning is here based on the i* strategicdependency diagram’s goals. Moreover, when plan-ning a project with an iterative SDLC, one needs ageneric process template. For this matter, we define,in this paper, an ”UP-compliant” reference frameworkin line with existing theory on iterative SDLCs. Thecontributions of this paper include this iterative tem-plate and a planning method illustrated with a runningexample based on the development of a productionmanagement system in the steel industry.

The paper is structured as follows: Section 2overviews a proposal for an iterative template for Tro-pos developments. Section 3 presents a MDA (model-driven architecture) method for iterative planning inthe context of I-Tropos developments. This methoddeal with threats and quality factors as fundamentalcriterias for goal prioritization. Section 4 points torelated work and finally Section 5 gives the reader aconclusion.

2 ITERATIVE TEMPLATE

The first proposal of this paper is to adopt the tradi-tional Tropos models and stages to define a projectmanagement template used to drive the software pro-cess. We also propose a common engineering termi-nology.

An ”I-Tropos development” is an extension of theTropos methodology, made of disciplines iterativelyrepeated while the relative effort spent on each one isvariable from one iteration to another. The phase anddiscipline notions are often presented as synonyms inthe software engineering literature. Indeed, Tropos isdescribed in (Castro et al., 2002) as composed of fivephases (Early Requirements, Late Requirements, Ar-chitectural Design, Detailed Design and Implemen-tation). However, the Software Process EngineeringMetamodel (OMG, 2005) defines a discipline asaparticular specialization of Package that partitionsthe Activities within a process according to a common”theme”, while a phase is defined asa specializationof WorkDefinition such that its precondition definesthe phase entry criteria and its goal (often called a”milestone”) defines the phase exit criteria. The Uni-fied Process (Kruchten, 2003) defines disciplines asacollection of activities that are all related to a major”area of concern” while the phaseshere are not thetraditional sequence of requirements analysis, design,coding, integration, and test. They are completely or-thogonal to the traditional phases. Each phase is con-

cluded by a major milestone.In order to be compliantwith the most generic terminology, traditional Troposphases will be called disciplines in our software pro-cess description since “they partition activities undera common theme”. In the same way, phases will beconsidered as groups of iterations which are work-flows with a minor milestone.

In I-Tropos, the Organizational Modeling and Re-quirements Engineering disciplines respectively cor-respond to Tropos’ Early and Late Requirements dis-ciplines. The Architectural and Detailed Design dis-ciplines correspond to the same stages of the tradi-tional Tropos process. I-Tropos includes core disci-plines, i.e.,Organizational Modeling, RequirementsEngineering, Architectural Design, Detailed Design,Implementation, Test and Deploymentbut also sup-port disciplines to handle the project developmentcalled Risk Management, Time Management, Qual-ity ManagementandSoftware Process Management.There is little need for support activities in a pro-cess using a waterfall SDLC since the core disci-plines are sequentially achieved once for all. How-ever, for an iterative process, the need for support dis-ciplines to manage the whole software project is fromprimary importance to precisely understand whichproject aspect to work on (and through which activ-ity) at a specific time and with the best resources. I-Tropos process’ disciplines are described extensivelyin (Wautelet, 2008).

Figure 1: I-Tropos: Iterative Perspective.

Using an iterative SDLC implies repeating pro-cess’ disciplines many times during the softwareproject. Each iteration belongs to one of the phasesusually four to six depending on the process itself,four in our case. We relate to the phases definedin the UP-based methodologies (RUP, OpenUP, EUP,...) but are redefined here to better match with theTropos specificities. These phases are achieved se-quentially and have different goals assessed at mile-

GOAL DRIVEN ITERATIVE SOFTWARE PROJECT MANAGEMENT

45

stones through knowledge and achievement orientedmetrics. Phases are informally described into the nextsection. Figure 1 offers a two dimensional view ofthe I-Tropos process depicting the disciplines on Y-axis and the four different phases they belong to onX-axis.

2.1 Core Disciplines

The I-Tropos process has been fully described us-ing the Software Engineering Process Metamodel in(Wautelet, 2008) that details each process’ Discipline,Activity, Role, WorkDefinition and WorkProduct, sothat it can be used as a reference, template, pattern orguide for managing the system project. A lightenedoverview of the is given below. As already pointedout, the first four disciplines are inspired by the Tro-pos original stage.

• the Organizational Modelingdiscipline aims tounderstand the problem by studying the existingorganizational setting;

• the Requirements Engineeringdiscipline extendsmodels created previously by including the sys-tem to-be, modeled as one or more actors;

• the Architectural Designdiscipline aims to buildthe system’s architecture specification, by orga-nizing the dependencies between the various sub-actors identified so far, in order to meet functionaland non-functional requirements of the system;

• theDetailed Designdiscipline aims at defining thebehavior of each architectural component in fur-ther detail;

• the Implementationdiscipline aims to produce anexecutable release of the application on the basisof the detailed design specification;

• theTestdiscipline aims on evaluating the qualityof the executable release;

• the Deploymentdiscipline aims to test the soft-ware in its final operational environment.

2.2 Support Disciplines

These support disciplines provide features to supportthe software development on a particular project i.e.,tools to manage threats, quality factors, time, effort,resources allocation but also the software process it-self. All those features can be regrouped onto the termsoftware project management (Jalote, 2002).

• Risk Managementis the process of identifying,analyzing, assessing risk as well as developing

strategies to manage it. Strategies include trans-ferring risk to another party, avoiding risk, reduc-ing its negative effects or accepting some or allof the consequences of a particular one. Techni-cal answers are available to manage risky issues.Choosing the right mean to deal with particularrisk is a matter of compromise between level ofsecurity and cost. This compromise requires anaccurate identification of the threats as well astheir adequate evaluation;

• Quality Managementis the process of ensuringthat quality expected and contracted with clientsis achieved throughout the project. Strategies in-clude defining quality issues and the minimumquality level for those issues. Technical answersare available to reach quality benchmarks. Choos-ing the right mean to deal with quality issues isa matter of compromise between level of qualityand cost. This compromise requires an accurateidentification of the quality benchmarks as wellas their adequate evaluation;

• Time Managementis the process of monitoringand controlling the resources (time, human andmaterial) spent on the activities and tasks of aproject. This discipline is of primary importancesince, on the basis of the risk and quality analyses,the global iterations time and human resourcesallocation are computed; they are revised duringeach iteration;

• Software Process Managementis the use of pro-cess engineering concepts, techniques, and prac-tices to explicitly monitor, control, and improvethe systems engineering process. The objec-tive of systems engineering process managementis to enable an organization to produce sys-tem/segment products according to plan while si-multaneously improving its ability to produce bet-ter products. In this context, Software ProcessManagement regroups the activities aimed to tai-lor the generic process onto a specific project aswell as improving the software process.

2.3 Process Phases

I-Tropos phases are inspired by UP-based processesand their milestones are based on the metrics from((Boehm, 1998)); each phase is made of one or moreiterations. Disciplines are conducted through thephases sequentially. Each phase has its own goal:

• theSettingphase is designed to identify and spec-ify most stakeholders requirements, have a firstapproach of the environment scope, identify and

ICSOFT 2011 - 6th International Conference on Software and Data Technologies

46

evaluate project’s threats and identify and evalu-ate quality factors;

• the Blueprinting phase is designed to producea consistent architecture for the system on thebasis of the identified requirements, eliminatemost risky features in priority and evaluateblueprints/prototypes to stakeholders;

• theBuildingphase is designed to build a workingapplication and validate developments;

• theSetupingphase is designed to finalize produc-tion, train users and document the system.

3 ITERATIVE PLANNING

This section describes a method for planning iterativeTropos developments. The relevant disciplines are il-lustrated on a running example, the development ofan enterprise information system in the steel industry.

3.1 Running Example: Coking Process

CARSID, a steel production company located in theWalloon region , is developing a production manage-ment software system for a coking plant. The aimis provide users, engineers and workers with toolsfor information management, process automation, re-source and production planning, decision making, etc.Coking is the process of heating coal into ovens totransform it into coke and remove volatile matter fromit. Metallurgical Coke is used as a fuel and reducingagent in the production of iron, steel, ferro-alloys, el-emental phosphorus, calcium carbide and numerousother production processes. It is also used to producecarbon electrodes and to agglomerate sinter and ironore pellets. The production of coke is one of the stepsof steel making but further details about other phasesof the production process are not necessary to under-stand the case study.

3.2 Agents for Steel Making

First of all, one question must be answered:How canan industrial domain such as the steel industry thatseems to belong to the past be interested in agent tech-nologies?In other wordswhy agent-oriented model-ing (and development) would be more indicated thantraditional - possibly object - technologies?

The steel industry is by essence an agent-orientedworld. Indeed, factories as a coking plant or a blastfurnace are made of hundreds of different types of

agents: software agents, machines, automates, hu-mans, sensors, releases, effectors, controllers, pyrom-eters, mobile devices, conveying belts, etc. These areagents in the sense that:

• they are autonomous and dedicated to specifictasks;

• they are situated in a physical environment;

• they can act upon their environment if this is nec-essary by warning users, proposing solutions ortaking autonomous action.

The whole I-Tropos project profile is illustrated inFigure 2. Rectangles represent the relative effort spenton each of the disciplines during each of the phases.Typically, the reader can notice that the effort spenton analysis disciplines (organizational modeling andrequirements engineering) is higher into the settingand blueprinting phases and marginal for the buildingand setuping ones. On the contrary, the design (archi-tectural design and detail design) and implementationones are marginal for the setting phase (at the earlybeginning of the project) and higher in the blueprint-ing and building phases. The project management dis-ciplines (i.e., the support disciplines) are addressedon a continuous basis with a stronger focus early onin the project (during the setting phase). We mostlyconcentrates in this paper on disciplines and activi-ties performed during the setting phase since the focusis to describe a method for iterative planning. Moreprecisely concerning the engineering disciplines, wewill only focus here on organizational modeling andrequirements engineering since they are the ones re-quired for model-driven planning. The support disci-plines will be covered in detail to depict the process ofgoal prioritization and development planning. How-ever, the support disciplineSoftware Process Man-agementis not covered here since it goes into toomany low-level details than we can afford in this re-search paper.

Elab #1Elab #1

Org. Modeling

Construction Transition

Tran #1

Construction TransitionBuilding Setuping

Tran #1

Req. Engineering

Architectural Design

Detailed Design

Implementation

Test

Deployment

Project Management

BlueprintingSetting

Setting Blue #1 SetupingBlue #2 Blue #3 Build #1 Buildt #2 Build #3

Figure 2: I-Tropos profile for the Carsid Coking Plantproject.


47

3.3 Engineering Disciplines

The i* framework can be evaluated on a series ofnine features following (Pastor et al., 2011):refine-ment, modularity, repeatability, complexity manage-ment, expressiveness, traceability, reusability, scal-ability and domain applicability. Those featuresare exhaustively assessed on the basis of anot sup-ported/not well supported/well supportedscale. No-tably they enlighten what is clearly needed to ex-tend the i* framework with mechanisms to managegranularity and refinement. Indeed, (Pastor et al.,2011) points out the lacks of mechanisms in i* fordefininggranulesof information at different abstrac-tion levels to structure, hierarchise or aggregate thesemantics represented in the model. One of theflaws of i* is actually that all of the organizationalmodeling elements are represented on a unique ab-straction level with poor hierarchy and composi-tion/aggregation. Moreover, except for specifying ab-stract primitives as building blocks, analysts must beprovided with guidelines to model a complete busi-ness setting through a set of organizational processes.These building entities could then be enriched into aset of more specific components that capture a certainorganizational behavior.

These discussions are from primary concern in theperspective of finding scope elements, i.e., primaryabstractions to drive the whole development processincluding support disciplines rather than just softwareengineering ones. Instead of defining a new modelreaching those criteria, as proposed in (Estrada et al.,2006; Pastor et al., 2011; Wautelet et al., 2008), werather prefer to provide guidelines to the software an-alysts in order to specify an i* strategic dependencymodel where each of the goals can be taken as inputinto the I-Tropos process. Those include:

• a goal must be defined at the highest abstractionlevel such as the organizational and strategic lev-els. Typically a scope element should describe aconceptual process, e.g., one business process sothat a goal must encapsulate a high level serviceprovided by the enterprise;

• lower level processes must be represented as tasksand a task must always be a refinement of a goal;

• goals are expressed independently, overlaps mustbe avoided and, if not possible, eventual redun-dancy among tasks of two different goals are ad-dressed at a lower level.

By respecting those rules, all the goals of the i*strategic dependency diagram (SDD) are scope ele-ments for breaking down the software project intomanageable parts and are taken as input in the sup-

port disciplines as shown in the next sections. Figure3 (also reproduced at the end of the document) repre-sents the SDD model built up following those rules onthe CARSID case study. Due to the lack of space wecannot detail each of the diagram elements here, nev-ertheless the reader should pay attention to the factsthat:

• Human Actorsare represented as circles, for ex-ample theFADS Teamis the team in charge ofhandling the coal reception;

• Equipment Actorsare also represented as cir-cles, for example theCoke Car is the automo-tive wagon that transports the red-hot coke to theQuenching Tower;

• Resourcesare represented as rectangles, for ex-ampleCoal is the raw coal received at the cokingplant;

• Goalsrepresented as rounded rectangles, for ex-ampleBaking is the process for which theOvenTeamsupervises the baking of the Coal Charge inthe Oven;

• Softgoals represented as clouds, for exampleQuality Cokerepresent the willingness of Man-agement to insure that the Coke produced in thecoking plant is good as the steel quality dependson the Coke quality;

• Tasksare represented as hexagonal forms, for ex-ampleBake is a sub-process of theBakinggoalonly concerned with the physical transformationof theCoal Chargeinto Coke.

Figure 3: Organizational Modeling.


48

3.4 Risk Management

The Risk Management discipline uses the goals iden-tified into the organizational modeling and require-ments analysis disciplines as fundamental scope el-ements. Consequently the identified threats are eval-uated on the basis of their impact on these elements.We define a threat asan event that can negatively af-fect the proper resolution of a goal or that can be theresult of the misuse of a goal execution both in termsof goal achievement and degradation of quality. Athreat is expressed as an aggregate risk with a quantifi-cation of the negative impact and a occurrence proba-bility. A threat is later refined into a series of softgoalswith respect to the transformation process.

Risk analysis was done in collaboration withstakeholders estimating and validating the possiblethreats impact. Risk quantification is done on a dou-ble basis. Firstly the general threat weight is esti-mated on the basis of the impact it can have on theproject under development, the system-to-be or theconcerned organization. Secondly, the involvementof each goal with respect to the risk evoked is eval-uated following aLow/Medium/Highscale. This hasled to the identification of six categories of threats:

• Requirements Poorly Understood: the systemdoes not run as expected. This threat is partic-ularly faced by user-intensive software applica-tions. This kind of risk has a weight of 3 sincehuge resources can be devoted to produce an in-adequate system;

• Facility Damage: it concerns the damages causedto production facilities. A representative exam-ple is when the pusher machine pushes while hotcoke is stuck in the oven, resulting in damagingthe pusher machine and/or the oven’s walls. Thiskind of risk has a weight of 2 since facilities re-pairs are cost-intensive;

• Mechanical Error: it concerns errors due to ma-chinery dysfunction. For instance, a failure in thecoke car engine, making impossible to cool downthe coke. This risk has a weight of 1 since it willdelay production;

• Human Injuries: it concerns injury (or even death)of the staff and/or workers. A coking plant is ahazardous place; a replacement worker was re-cently killed in a coke plant in Ohio, and othernumerous accident of this type took place in thepast. This risk has a weight of 3 since it is verycostly in terms of money and reputation;

• Human Error: it concerns errors due to humanintervention. This risk has a weight of 2 since itcan potentially lead to other risks.

• System Failure: the information system is notavailable. The system may be down and cannotbe used for a certain amount of time. This riskhas a weight of 1 because it will delay production.

• Data Loss: some needed data is lost or never ex-isted. It may happen if one of the worker forgetsto encode some data. This risk has a weight of2 because it will delay production and can poten-tially lead to other risks.

On the basis of the organizational model of Figure3 and the risk analysis, the matrix in Figure 4 sum-marizes the impact of the identified threats onto themodeled goals. A specific goal is facing a particu-lar threat is the marked and a measure is given. Forexample the goalAligning faces the threatMechani-cal Error even if the probability of occurence of thethreat on the goal remainsLow. The overall risk ex-posure of each goal is finally computed on the basisof the threats they faced, the intensity and the threat’sweight.

3.5 Quality Management

The Quality Management discipline uses the goalsidentified into the organizational modeling and re-quirements analysis disciplines as fundamental scopeelements. Consequently the identifiedQuality Fac-tors are envisaged on the basis of their impact onthem. Quality factors must firstly be distinguishedfrom traditional softgoals in the sense defined in(Chung et al., 2000). Since we address a higher levelbusiness view of the system to-be, we need an abstrac-tion where we can specify the quality concerns of thesystem rather than its states as softgoals would char-acterize. In this sense, softgoals describe functionsof a system while quality factors do not. We definea threat asa constraint onto one or more goals in theform of a degree of excellence. A quality factor is laterrefined into a serie of softgoals in the transformationprocess.

Quality analysis was done in collaboration withstakeholders estimating and validating the possiblequality factors impact. That work has led to the iden-tification of six categories of quality factors:

• Reliability: Software Reliability is the probabilityof failure-prone software operation for a specifiedperiod of time in a specified environment. Thisquality factor deals with the question:What levelof trust can be placed in what the system does?

• Efficiency: Software Efficiency deals with execu-tion time, the later can be influenced by sourcecode optimization, the use of performing algo-rithmic techniques, faster sequential execution or


49

Threatweight

Aligning

Baking

Blending

Charging

Cooling

CreatingPushingPlanning

Inversing

Loading

ManageProductionPro

cess

Pushing

ReachingPosition

ReceptionHandling

RecordingInformation

RecordingTemperature

RetrievingInformation

Setting

Requirements poorly understood HHL3

Facility damage 2 L L L M H L

Mechanical error 1 L L L M M L M M M L

Human injury 3 L L M L L L

Human error HHMM2

System failure LLLM1

Data loss MMM2

80153101531810150127131erusopxEksiRlaoG

Figure 4: Project Goals Risk Exposure.

code parallelization. This quality factor deals withthe question:How well are resources utilized?

• Usability: Software Usability is the capability ofthe software product to be understood, learned,used and attractive to the user, when used un-der specified conditions. This quality factor dealswith the question:How easy is it to use?

• Integrity: Software Integrity is the ability of soft-ware to resist, tolerate and recover from eventsthat threaten its dependability. This quality fac-tor deals with the question:How secure is it?

• Testability: Software testability is a software char-acteristic that refers to the ease with which someformal or informal testing criteria can be satisfied.This quality factor deals with the question:Howeasy is it to verify conformance to requirements?

• Flexibility: Software flexibility is the ability of asoftware system to adapt to change. This qualityfactor deals with the question:How easy is it tomodify?

• Interoperability: Software interoperability is de-fined as the ability for multiple software compo-nents written in different programming languagesand distributed across multiple platforms to com-municate and interact with one another. This qual-ity factor deals with the question:How easy is itto interface with another system?

Based on the organizational model in Figure 3 andthe quality analysis, the matrix in Figure 5 summa-rizes the impact of the identified quality factors ontothe modeled goals. A goal facing a particular qualityfactor is marked and a measure is given, for examplethe goalAligning faces the quality factorEfficiencyeven if the concern remainsLow. The overall qualityfactor exposure of each goal is finally computed on

the basis of the quality factors they faced, the inten-sity and the quality factor’s weight.

3.6 Time Management

The previous two sections studied the threats andquality factors impact on the goals from the SDD.This section uses the global risk and quality expo-sures to determine a goal priority. Indeed, within thedefined iterative life cycle we will plan the goals’ re-alization. Goals with highest priority will firstly bedesigned, prototyped and tested during theBlueprint-ing phase and then implemented during theBuildingphase. This allows scrutinizing the trickiest issuesfirst so that risks are addressed early on in the projectwhen corrective actions are easier and cheaper to putinto practice.

The relevant concepts and their computations aresummarized in Figure 6.Particularly, we emphasizethat:

• TheOverall Risk Exposureis the sum of all threatsinvolvement at any level on one goal;

• TheTotal Risk Exposureis the sum of theOverallRisk Exposureof all the project goals;

• On the basis of theOverall Risk Exposure, theRelative Risk Exposureis computed using the for-mula:RelativeRiskExposure= OverallRiskExposure

TotalRiskExposure;

• TheOverall Quality Exposureis the sum of all thelevels of involvement of all the quality factors onone goal;

• The Total Quality Exposureis the sum of theOverall Quality Exposureof all the project goals;

• On the basis of theOverall Quality Exposure,the Relative Quality Exposureis computed us-


50

QualityFactorWeight

Aligning

Baking

Blending

Charging

Cooling

CreatingPushingPlanning

Inversing

Loading

ManageProductionPro

cess

Pushing

ReachingPosition

ReceptionHandling

RecordingInformation

RecordingTemperature

RetrievingInformation

Setting

Reliability 3 M L M M H M H M H L

E ciency 2 L L H H M L L L M M

Usability MMM1

Integrity MMHML3

Testability 1 L L L M L L M M L M L

Flexibility 2 M M L H L M M M M

Interoperability 2 M L L L L L M L M M L

Goal Quality Exposure 16 3 1 11 5 31 1 5 32 20 16 1 30 18 26 14

Figure 5: Project Goals Quality Issues.

OverallRiskExposure

RelativeRiskExposure

OverallQualityExposure

RelativeQualityExposure

PriorityLevel

GoalPriority

GoalComplexity

GoalComplexityWeight

Precedence

1 Aligning 1 0,008264463 16 0,069565217 0,023589651 13 L 5

2 Baking 3 0,024793388 3 0,013043478 0,021855911 14 L 5

3 Blending 1 0,008264463 1 0,004347826 0,007285304 16 M 10

4 Charging 7 0,05785124 11 0,047826087 0,055344951 9 M 10

5 Cooling 2 0,016528926 5 0,02173913 0,017831477 15 M 10

6 Creating Pushing Planing 10 0,082644628 31 0,134782609 0,095679123 4 H 15 G4, G10

7 Inversing 5 0,041322314 1 0,004347826 0,032078692 12 L 5

8 Loading 10 0,082644628 5 0,02173913 0,067418254 6 M 10

9 Manage Production Process 18 0,148760331 32 0,139130435 0,146352857 1 H 15

10 Pushing 13 0,107438017 20 0,086956522 0,102317643 3 H 15

11 Reaching Position 5 0,041322314 16 0,069565217 0,04838304 11 M 10

12 Reception Handling 10 0,082644628 1 0,004347826 0,063070428 8 L 5

13 Recording Information 13 0,107438017 30 0,130434783 0,113187208 2 L 5

14 Recording Temperature 5 0,041322314 18 0,07826087 0,050556953 10 L 5

15 Retrieving Information 10 0,082644628 26 0,113043478 0,090244341 5 M 10 G13

16 Setting 8 0,066115702 14 0,060869565 0,064804168 7 M 10

541110321121

Goal

Sum

Figure 6: Goal Prioritization.

ing the formula: RelativeQualityExposure=OverallQualityExposureTotalQualityExposure;

• ThePriority Levelis computed by ”balancing” theRelative Risk Exposureand theRelative QualityExposure. For this particular project we chose arepartition key of 75 percent for the risk compo-nent and 25 for the quality component. This repar-tition key can vary from one project to anotherand should be calibrated from data collected ona large number of projects as well as consideringthe working team experience;

• On the basis of thePriority Level, eachGoals Pri-ority is deduced.

On the basis of theGoal Priority list, thePrece-denceconstraints and the estimatedGoal Complex-

ity we instanciate the iteration template defined inSection 2. The process is summarized in Figure 7.The Goal complexity estimates the amount of ef-fort required to develop it. I-Tropos uses three cat-egories of goal complexity, i.e.,Low/Medium/High,owning respectively a weight of5/10/15. Transform-ing the overall weight to man-month requires cali-bration typically based on a regression model usingstatistics from large numbers of projects and remainsan open issue. The proposed planning will be subjectto modifications/reviews during the software projectsupported by users and environmental feedbacks.


51

Priority

Complexity

Elaboration1

Elaboration2

Elaboration3

Construction1

Construction2

Construction3

1 Manage Production Process XXH1

2 Recording Information XXL2

3 Pushing XXH3

4 Charging XXM9

5 Creating Pushing Planing XXH4

6 Retrieving Information XXM5

7 Loading XXM6

8 Setting XXM7

9 Reception Handling XXL8

10 Recording Température XXL01

11 Reaching Position XXM11

12 Inversing XXL21

13 Aligning XXL31

14 Baking XXL41

15 Cooling XXM51

16 Blending XXM61

145 15 16,66667 16,66667 30 33,33333 33,33333

Goal

Total E!ort Weight

Figure 7: Iteration Plan.

4 RELATED WORK

Numerous agent-oriented software developmentmethodologies have been proposed in the past twentyyears. We overview hereafter some of them witha particular focus on iterative SDLC and softwareproject management. Tropos (Castro et al., 2002)offers the most advanced agent-based modelingfeatures through the i* models, one of the reasonswe use it as a basis for the process presented in thispaper. Some papers related to this methodologypropose to develop a software system in an iterativelyway but no supporting theoretical framework hasever been proposed. Gaia (Zambonelli et al., 2003),one of the most popular methodologies due to itssimple and clear process as weel as its neutralitywith respect to implementation techniques or plat-forms has been extended with an iterative SDLCin (Gonzalez-Palacios and Luck, 2007). The maindrawback of their proposal is that they decomposefunctionality on the basis of design models (called”parts”) and not analysis ones. Moreover, the prioritygiven to those functional parts is done in anad hocmanner since no framework is given to evaluate thecriticality of these ”functional parts”. There is also noreal template provided for cutting out the project intophases so that each iteration can be considered as a”sub-waterfall project” with no rapid prototyping fortesting as implied by the cut out between blueprintingand building phases in our framework. ADELFE(Bernon et al., 2002) claims to follow the RUPbut no guideline or planning method is actuallygiven for that purpose. The process is depicted in(Bernon et al., 2002) in a waterfall manner. Finally,MASSIVE (Lind, 2001) uses anIterative ViewEngineeringapproach itself based onIterative

EnhancementandRound-trip Engineering. From theauthors’ point of view, the method can be said to beincremental rather than iterative. As a matter of fact,it is founded on producing hybrid models to be testedand enhanced later on into the project on the basisof users’ feedback. However, the software project isnot broken down into manageable elements that areprioritized and worked on during multiple iterationsso that no software project management framework isrequired to manage the SDLC.

5 CONCLUSIONS

Since the emergence of spiral development, softwareengineering professionals have learned the benefits ofiterative approaches. However, poor guidelines andproject management frameworks have provided prac-tioners with clear methods to deal with such SDLCsin a structured manner. Moreover, MDA (Model-Driven Architecture) and MDD (Model-Driven De-velopment) is extensively used in the software trans-formation process i.e., the process of tracing highlevel analysis elements into design and implementa-tion ones. This principle is applied here but analysismodels are used to feed the process at the manageriallevel for goal-driven project management.

Finally, the process needs to gain experience, ithas recently been applied (and has given encouragingresults) on the development of a collaborative supplychain management platform with an in-depth anal-ysis of the empirical results. The method can alsobe very easily and flexibly adapted to UML use-casedriven development and serve RUP practioners intheir everyday iterative object-oriented developmentplanning.


52

REFERENCES

Bernon, C., Gleizes, M. P., Picard, G., and Glize, P. (2002).The adelfe methodology for an intranet system design.In Giorgini, P., Lesperance, Y., Wagner, G., and Yu,E. S. K., editors,AOIS@CAiSE, volume 57 ofCEURWorkshop Proceedings. CEUR-WS.org.

Boehm, B. (1998). Software Project Management.Addison-Wesley.

Castro, J., Kolp, M., and Mylopoulos, J. (2002). To-wards requirements-driven information systems engi-neering: the tropos project.Inf. Syst., 27(6):365–389.

Chung, L., Nixon, B., Yu, E., and Mylopoulos, J. (2000).Non-functional requirements in software engineering.Kluwer Academic Publishing.

Estrada, H., Rebollar, A., Pastor, O., and Mylopoulos, J.(2006). An empirical evaluation of the i* frameworkin a model-based software generation environment.Proceedings of CAiSE, pages 513–527.

Gonzalez-Palacios, J. and Luck, M. (2007). Extending gaiawith agent design and iterative development. In Luck,M. and Padgham, L., editors,AOSE, volume 4951of Lecture Notes in Computer Science, pages 16–30.Springer.

Jalote, P. (2002).Software Project Management in Practice.Addison Wesley.

Kruchten, P. (2003).The Rational Unified Process : AnIntroduction. Addison-Wesley, 3 edition.

Lind, J. (2001).Iterative Software Engineering for Multia-gent Systems: The MASSIVE Method, volume 1994 ofLecture Notes in Computer Science. Springer.

OMG (2005). The software process engineering metamodelspecification. version 1.1. Technical report, ObjectManagement Group.

Pastor, O., Estrada, H., and Martınez, A. (2011). Thestrengths and weaknesses of the i* framework: an ex-perimental evaluation.in Giorgini P., Maiden N., My-lopoulos J., Eric Yu editors, Social Modeling for Re-quirements Engineering, in Cooperative InformationSystems series, MIT Press.

Wautelet, Y. (2008). A goal-driven project manage-ment framework for multi-agent software develop-ment: The case of i-tropos.Unpublished PhD the-sis, Universite catholique de Louvain, Louvain Schoolof Management (LSM), Louvain-La-Neuve, Belgium,August.

Wautelet, Y., Achbany, Y., and Kolp, M. (2008). A service-oriented framework for mas modeling. In Cordeiro, J.and Filipe, J., editors,ICEIS (3-1), pages 120–128.

Yu, E. (1995). Modeling strategic relationships for processreengineering.PhD thesis, University of Toronto, De-partment of Computer Science, Canada.

Yu, E. (2011).Social Modeling for Requirements Engineer-ing. MIT Press.

Zambonelli, F., Jennings, N. R., and Wooldridge, M.(2003). Developing multiagent systems: The gaiamethodology. ACM Trans. Softw. Eng. Methodol.,12(3):317–370.


53

goal driven iterative software project management - lirias

Documents