Rubik's Cube Model of Software Engineering For Incremental and Legacy Projects

JOURNAL OF COMPUTING, VOLUME 3, ISSUE 2, FEBRUARY 2011, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG 99
Rubik’s Cube Model of Software Engineering for Incremental and
legacy projects
Ajay Jain
Abstract - In today’s Software development life cycle, technologies are getting complex, dependencies across
components are increasing, resources are getting limited, and time to market is getting shorter. Therefore, it is
extremely important to invent and adopt a project development approach that successfully addresses these
issues. The development model should ensure that component changes are well absorbed and integrated in
time, product features are always ready for client’s showcase, and iterative development work packages are
delivered in time to manage project risks effectively. In this paper, I propose the Rubik’s Cube Model (RCM)
of Software Engineering.
The RCM is simulated by dividing the entire project into multiple logical components, and each component is
further divided into interrelated sub-components. It helps in identifying relations and dependencies across
components and modules. This model allows simultaneous execution and quick integration and absorption of
change requests across components without altering any project goals. It allows critical time saving throughout
the project cycle.
Keywords: Software development model, project life cycle, process model, concurrent processing, software
Engineering.
INTRODUCTION
A software development methodology [1, 2, 3, 4, 5] refers to a framework used to structure, plan, and control
the process of developing an information system. The framework of a software development methodology
includes:
 A software development approach (or model) mapping the development process to specific and
substantial deliverables.
 Multiple tools and methods to assist the development process.
Software development models generally specify a set of stages in which a project is logically partitioned and
an execution order within the specified set of constraints and conditions at each stage.
There are various software development models evolved in the industry over the years. Each model has its own
advantages, limitations, and constraints. These models are often bound to some organization, which further
develops, supports, and promotes the methodology. A specific development model might not be suitable for all
projects. Technology, resources constraints, time to market, and rapidly changing customer needs are different
factors that a Project Manager must consider to evaluate and adopt a development model for a given project
cycle.
While some models are suitable for small projects where requirements are generally frozen or remains
unchanged during entire project cycle, some models cater to large projects where a working deliverable is
expected at every agreed upon milestone for generating customer’s confidence. Some models require close
collaboration among various project stakeholders (for example, development and testing teams).
Another critical and practical aspect is carrying legacy code in the project for certain number of milestones
before the new code is written, which replaces the legacy code. Development teams cannot afford to remove
the legacy code at the start of the project for various reasons. For example, the new technology/feature
generally takes at least a few milestones to release deliverable for integration and customers are not ready to
accept the code that does not carry this critical feature in working mode (applies to legacy or new
development).
EVOLUTION OF PROCESS MODELS
Let us have a quick review of key and widely known development models that drove a significant number of
projects in the Software Engineering history.
Waterfall Model:
Winston Royce [6] first proposed this model, which eventually became the most influential and commonly
used model in software development. The key concept proposed in this model is the linear approach among the
various project development stages. This approach results in keeping the model easy and requires low
administration with each milestone carrying specific checks.
Royce do suggested looping back data

Requirements
from testing stage to design stage and
ultimately to requirements stages for
Analysis
more robust flow. This model also
covers iterative relationship between
successive development phases. Design
These steps or phases are logically Coding

ordered in order to provide a sequential
flow of data from one phase to other.
Testing
Output of current phase acts as input for
next phase and so on. The key stages in
the Waterfall model are Requirements Figure 1: Implementation steps as per Waterfall
Model(System/Software), Analysis,
Program Design, Coding, and Testing.
The limitations associated with the Waterfall model are as follows:

There is no opportunity to go back multiple levels, especially if the requirements are changed. It requires single
delivery of the project.
The Waterfall model doesn’t fit the current development scenario for the following reasons:
The product requirements change during the project cycle to have a competitive product at the end of the cycle.
The customers want to experience the product as it is developed. In most cases, the development cycle
continues only after customers validate the product delivery at each milestone.
Iterative/Spiral Model
The spiral model addresses the limitations of the Waterfall model. The methodology used in this model is
building and delivering the project in small iterations. The concept it follows is “build a little, test little”, which
means that the key features are built and delivered for customer for approval and commitment to go ahead
further. In the following iterations, the remaining set of features are integrated and the product is again made
into a working prototype.
The commonly used iterative development approach is organized as a sequential progress of iterations, with
each iteration delivering parts of the functionality. The main advantage of this model is that it reduces the risk
of missing any explicit or implicit requirements. It leads to a minimal chance of rework; the maximum possible
rework can be rolling back to the previous iteration). It is not necessary to baseline and freezes the
requirements at the very start of the project. Customer demands may change and accordingly requirements
evolve during the project cycle. It is also a customer-friendly methodology as they do not have to wait for the
complete project cycle test the product features. They can suggest changes at any stage during the development
cycle. This is primarily applicable for projects where requirements are not baseline or are implicit in nature.
Agile methodology
Agile modeling [11] gives more weigtage
to flexibility, collaboration, and customer
satisfaction. Based on values and
principles, agile promotes close interaction
between various project stakeholders. It is
most useful in projects where teams are
highly disciplined, skilled, and co-located.
In this model, the project is divided into

multiple Sprints where each sprint carries a
selected set of features to be developed,
tested, and demonstrated to the customer.
Figure 2: Sprint Modeling
The customer reviews and gives feedback, which is then looped back to the engineering teams. The figure [8]
displays the selective feature selection (features 1, 2, 4, and 7) for development in a specific sprint.
Agile method is a family of development processes. In 2001, experts in the field of agile development came
together at the Snowbird ski resort in Utah to discuss ways of creating software in a lighter, faster, more
people-centric way. They coined the term Agile Software Development. www.agilealliance.com [9, 10]
Sprint is basic unit of development in the Scrum development methodology and other agile development
methodologies. Sprints tend to last from one week to a month, and are a time-boxed effort of a constant length.
PROPOSED MODEL
The proposed Rubik’s Cube Methodology (RCM) is a general-purpose methodology, which is extremely
useful in today’s software development life cycle. It is especially applicable for incremental and legacy
projects. The methodology suggests breaking software projects into logical components integrated together
with defined interfaces. Identification and naming of these logical modules (analogous to sides of Rubik’s
cube) is up to the Project manager.
Following are the salient interpretations and behavioral aspects of RCM:
 A Project is a multi-dimensional entity, which means that every project can be broken down into multiple
associated components.
 It is not necessary for each component to interact with other components.
 Some components require close interaction with each other.
 Each component can be broken into multiple logical sub-
components.
 Multiple components can be developed and worked upon in
parallel.
 Projects are flexible. During the project cycle, focus can shift
from one development area to another for various internal or
external factors, such as resources and business need
constraints, without impacting the final project goals.
 One component can be completed on a standalone basis for
achieving internal milestone based goals, even if the
remaining components are not complete.
 The sequence and state of developing component need not be
fixed. A component, which is once complete, can be brought
back into a development state for achieving business
objective and project level completion.
Figure 3: 3-D View of the Rubik’s Cube
The following section describes each of these aspects in detail.
Key Aspects of RCM
RCM is based on the logic, which conceives software development projects as the Rubik’s Cube. Projects
behaviors, functionalities, dependencies, inter-relations, and other project parameters can be mapped to how
Rubik’s cube operates.
A Project is a multi-dimensional entity, which means that every project can be broken down into multiple
associated components.
RCM suggests every project can be decomposed and broken into multiple small components. When these
components interact, they represent the complete project. The methodology suggests it is always advantageous
to divide a complete project into logical components. It is recommended to identify grouping of data and
processes as separate RCM entities. Using this approach, a Project Manager can decompose the project with
categorization related to software development phases [13] (e.g. decomposing into Requirements, Design,
Coding, Testing) as data entities and include Metrics and related Processes under the project processes
entities. RCM takes the six available sides of the physical Rubik’s cube and highlights them as six entities of a
software development projects. Refer figure 3 above.
The four sides (in any order) of this model are mapped to different software phases (or different project
modules). The data entity includes:
Requirements (6 in Figure 3)
Design (3 in Figure 3)
Code (2 in Figure 3)
Test (4 in Figure 3)
The remaining two sides (1 and 5 in Figure 3) are

interpreted as processes entities, which interact with all
four data entities (sides) in some or other way and are
designated as:
Processes (1 in Figure 3)
Metrics (5 in Figure 3) Figure 4: Rubik’s cube in two dimensions
The interaction of Processes and Metrics with each of the four key data entities viz. Requirements, Design,
Code, and Test are discussed in detail later.
It is not necessary for each component to interact with other components.
Although RCM divides a project into multiple components, it is not always necessary for each component to
interact with other components. While communication across components is the key, it is not mandatory that
each component talks to every other component directly. Sometimes the communication is achieved via an
interfacing component. For example, to execute acceptance test functionality at a customer’s site, it is not
always required to view the code base that generates the executable for the project. Another example is an
application feature, which can only be used once the application is successfully installed and licensed by the
user. In this case, if the user simply installs the application but does not activate it and tries to invoke the
feature, it will not work because its usage is tied to the activation and not with the installation. Presence of a
feature means product is installed successfully, but successful installation does not necessarily mean usage of
the application. Communication should be channelized via a licensing and activation component.
See Figure 5 for a diagrammatic interpretation of how data flows across components.
Figure 5: Communication using Intermediate Channel

In Figure 5, traversing the path from A to B will not fetch relevant results, though application is installed via
step A and is visible to the user but the feature cannot be used unless the application is activated. This means
that the communication of A to B must go via an intermediate channel C. RCM stresses this point, it is not
necessary for each module to interact with every other module in the project.
Some components require more frequent interaction amongst them than other components.
In every project, there are components that have much more tightly coupled relationship among them
compared to other components. These components require a much higher frequency of data sync and
intelligent checks between them for the project to work successfully. Consider a case where multiple products’
features are installation, licensing, updater, product specific features, and workflows. In this case, while
product specific features and updater talk to each other with a very low frequency, licensing and installer
components interact on a much larger scale. Installation and Licensing are interdependent and close to each
other in terms of functionalities and feature invoking dependencies on each other. Licensing cannot work
unless the product is installed and the parameters have right states set in the database.
Figure 6: Frequent Communication across Components
Multiple components can be developed and worked upon in parallel.
RCM model advocates sprint methodology, and if carefully planned, multiple components can be developed in
parallel without any immediate dependency across components. There are no limitations to perform only one
development task at a time. Customers generally request multiple (set of) features. While there is a sequential
dependency among some of the features, there are other set of features that are not so tightly coupled to each
other and can be developed simultaneously. This results into efficient and timely utilization of human
resources, machines, and inventory. In the agile methodology too, (as shown in figure 2) a set of features
(feature 1, 2, 4, 7) are selected for parallel development and were delivered as part of specific sprint. Similarly,
the next development phase can select another set of features, development tasks for working in parallel. In
terms of software development phases, it’s not required that coding and testing are performed in one way
sequence and that too only when all requirements are frozen. RCM suggests parallel work on test plan and
strategy preparation, test data sampling, while the code is getting written for initial set of
baseline/frozen/implicit requirements.
Each individual component can be broken into multiple logical sub-components
RCM suggests that each component of a software development project can be divided into logical sub-
components. These sub-components help in managing, controlling, and developing the bigger component. All
6 entities are detailed in the below table.
Requirements Design Coding Testing
 Implicit vs. Explicit  Architecture  Programming  Test coverage

requirements  High level design Language  Conditional
 User acceptance  Low level design  Scripts coverage
 Prototype  Performance aspects  Code written  Functional coverage
 Requirement of design manually vs. Code  Acceptance testing
Management tools  Security inbuilt generated via tool  Stress testing
 Requirement  Scalability  Code coverage  Security testing
traceability matrix  Modular structure  Coding practices  Performance testing
 Requirements  Platform dependent  Black Box vs. White
approval chain or platform Box testing
 User Stories. independent code  Automation vs.
Manual testing
 Test Plan
 Test Strategy
 Test Data
 Bugs Handling
Process Metrics
 Requirements capture process  Requirements (Implicit/ Explicit)

 Wiki / MS Excel sheets or Word documents  Requirements addressed (vs. dropped)
 User stories  Product backlog items and spread across
 Tools (internally developed or purchased milestones
from market)  Development and test estimation
 Traceability matrix  Burn down rate1 [12]
 Customer visits, sync dev meetings  Code coverage – functional and conditional
 Prototype reviews  Test coverage
 Design Process  Bugs detected via code reviews, peer
 Design reviews reviews
 Architecture council  Bugs detected via test execution
 Impact analysis  Bugs detected within team and outside
 Performance parameters teams (clients)
 Approval Gate checks  Bug efficiency (bugs fixed vs. bugs
 Code Process withdrawn)
 Coding guidelines  Bug bounce rate (investigating as to why
 Peer reviews bug fix failed)
 Code check-in process  Count of ship blocker bugs
 Build process  Prerelease logged bugs and their efficiency
 Code – unit Test process
 Impact Analysis
 Test process, Traceability matrix
 Test plan, approval, Test estimates
 Bug cycle process 1
A burn down chart is a graphical representation of
 Bug review council and approval
 User acceptance work left to do versus time.
Projects are flexible
In RCM, projects are handled with utmost flexibility. During the project cycle, sometimes there occurs a need
of shift focus from one development area to another. This need is generated because of various controlled (or
uncontrolled), internal (or external) factors, such as resource constraints or changing business priorities.
However, with strategic planning and prioritizing feature sets, the final and overarching project goals can be
achieved, because RCM allows parallel development on any components any time.
A component can be completed for achieving internal milestone-based goals, even when the remaining
modules are not complete.
This is one of the core aspects of RCM and analogous to physical Rubik’s cube object’s behavior. Rubik’s
cube is made up of six blocks of different colors (for example, Red, Blue, Green, White, Black, and Yellow).It
is easier to quickly solve one side of the Rubik’s cube, while the other five sides are still a mix of the
remaining five colors. The RCM based software engineering projects also behave in the same way. A working
prototype of a part of the project is made and demonstrated to the customer. This prototype is similar to one
completed block of the Rubik’s cube. The partial completion helps in communicating the ability and
confidence of the development team to meet first level of customer’s requirements within time.
It is not always necessary to complete all modules in a specific sequence.
RCM, to an extent, follows techniques of agile methodology where project schedule is divided into multiple
sprints. Each sprint picks up some key feature(s) for development in specific sprints. There is no strict
requirement of picking features sequentially. For example, if there are 10 features in a complete project, it is
not necessary to start with feature 1 first and then follow a regular mathematical sequence. However, if there is
a logical dependency chain between multiple features, RCM respects the sequence.
Any feature can be developed any time by taking into account all dependencies. Sometimes, extensive testing
is paused for the next sprint in order to provide a vast testing coverage if there are more features coming up.
Generally, the low priority features are skipped to last phases (or sprints) of the project even when they are
documented in the requirements during an early stage. Similar is the behavior of Rubik’s cube, you can keep
working on matching the color of the blocks, but it is not restricted to move in one specific direction and solve
one particular side. Sometimes, you align some Red blocks (equivalent to one software component), then leave
them and start aligning the Blue blocks (equivalent to other software component). This random order of color
selection (module selection) continues until all color patterns are aligned. There is no specific direction or
identified path where only a particular color is to be referenced.
The sequence and state of developing component need not be fixed.
A component, which is once complete, can be brought back into a development state for achieving business
objective and project level delivery. This is another important aspect of RCM, especially applicable to both,
legacy code based projects or incremental type of software development projects. Legacy projects are the ones
in which a big chunk of code and functionalities are retained even when the project enters a new cycle.
Because there is a strong user base associated with the project, the software cannot be brought down for a long
duration. The goal of these project cycle is to bring in (or replace) the old technology (legacy code with
features based on new technology that is to be built within the team, but will take multiple sprints.
Because of the multiple reasons, it is possible that the project needs to keep one specific component complete
and active for some sprints while the rest of the project modules are in constant development phase. Knowing
that a replacement of this currently active legacy component is in development phase but this legacy
component is kept alive to perform key customer facing business aspects. It allows continuous delivery of
functionality in the legacy project without getting impacted by the in-development components. When the
development of the new module is complete, and new component is ready for integration, the old legacy
module is replaced with the newly developed features, keeping the project downtime extremely low. Some
product users (for example, prerelease users) might not even know that the legacy code based component have
been replaced with a newly written component altogether. This logic is applicable for incremental software
development project too where each sprint will result in building complete components ready for customer’s
reviews and demos. These once delivered complete components can go back to development phase because of
their dependencies on the new features developments planned for upcoming sprints. Equal weight age and
independent components can be developed in parallel and not necessarily required to be in a predefined
sequence.
Interphase communication in RCM:
RCM suggests breaking software projects into logical components attached to each other with defined
interfaces. The identification strategy for components suggested by RCM, is to divide all components into data
and processes as logical entities. A set of components can be identified under the data group of entities where
close interaction, data flow and communication across sub-components, happens regularly. It is considered the
backbone of the project functionalities and features. On the other hand, the Processes entities help in binding
the project, keeping the integrity, and deciding the limiting boundaries of the project. Data entities represent
the logical view, whereas processes define the organizational view. Each data block interacts with its neighbor
data blocks. Any further communication with the blocks that are not directly bonded to the data block will
enable the communication through successive (or intermediate) block or the process layer.
In the inter-phase communication, we do a separate treatment of data and processes, where the data view is
modeled in three stages - conceptual, logical, and physical. Similarly, the process-oriented view passes through
the same three stages of conceptual, organizational and operational. These stages in the modeling process are
paralleled by the stages of the life cycle: strategic planning, preliminary and detailed study, development, and
implementation and maintenance.
Figure 8: Communication channel across various project phase
Figure 8 shows the communication medium and channel for letting each component talk to each other. In some
cases, two components reside in separate objects and interact via an intermediate layer (or channel). In some
cases, two neighboring components have direct interaction with them. If we make an analogy of Rubik’s cube
sides with that of software engineering development phases, we mean that requirements and design phases (or
modules) are communicating with each other closely and directly. All requirements should be mapped to a
specific design to convert customer’s requirements to a substantial working deliverable. Design (high level or
low level) is then passed to the developer for converting the architecture to the programming code. It is then
shared with the testing team for testing and completing user acceptance. Testing items are then mapped to the
individual requirements via traceability matrix to ensure each requirement (implicit or explicit) is available in
the product.
Two layers (top and bottom) encompassing (or controlling, limiting) the core four entities of the development
projects are interpreted as “Processes” layer and “Metrics” layer in the RCM model. Process helps in
recommending, guiding the methodology, and defining the approach for smooth, defined interaction amongst
each module. Metrics help in binding the project together, limiting and ensuring all project deliverables are on
track against all the goals, and their defined values. Metrics help in setting up control limits and project goals
across all components. Without metrics, it is very difficult to predict if the progress is really on track and
within controlled parameters. Each project has its own set of metrics and it’s highly recommended for the
Project Manager to choose the appropriate metrics. It is recommended not to collect many but useful and
important metrics. More metrics tend to result in more the data, which is difficult to interpret and logically
conclude the data.
Let us now take a case study that uses RCM by shuffling internal priorities (like sides of a rubik’s cube),
develops a new technology in house (like completing one section of a rubik’s cube) and replaces the old
(running) technology (like dismantling a completed side of a Rubik’s cube) with a new licensing technology
(allowing other sides of the Rubik’s cube to bring same color component by dismantling the solved side).
CASE STUDY
Project Goal: Build and replace the existing licensing technology (third party) with in-house developed
technology in the upcoming product release. It requires legacy code removal and integration of the new code.
Description: A legacy project (three cycles already released to the field) integrates the licensing module
technology provided by a third-party vendor. Now, we will not go into business related discussions that went
in when signing the deal with this third party vendor.
The field observations after reviewing the three release cycles are as follows:
1) Customer issues count on licensing technology is huge (say, count = N), n= 0, 1,2…N
2) Dollars spent on addressing customer calls and providing technical support is high (say $A per call)
3) Third party contract/support (for each cycle) cost is $B.
In addition to above three points, customer pain and impact to the brand value of the company offerings is
something that cannot be directly measured in terms of dollar amount, although there are ways (like surveys,
JOURNAL OF COMPUTIN NG, VOLUME 3,3 ISSUE 2, FEB
BRUARY 2011, ISSN 2151-96117
HTTPS://SIITES.GOOGLE..COM/SITE/JOU
URNALOFCOM MPUTING/
WWW.JOU URNALOFCOM MPUTING.ORG 109
net promooter scores etcc) that can be used but quanntifying them to an equivallent dollar am
mount but associated
them specifically with liicensing technnology might be
b tough.
The total cost for contin

nuing with thiird party licenssing technologgy is:
ThirdPartyyCost TC= ∑ (N*$A + $B)
In order too mitigate thee points from the field revieew, the strategy identified is to build ann in-house liceensing
technologyy. Various parrameters invollved in quantiffying the efforrts are as folloows:
1)) Number off developers/teesters needed: w (number off people)

2)) Duration of developmentt/testing: x (m
months)
3)) Integration
n effort: y (monnths)
4)) Integration
n team: z (nummber of people))
5)) Average saalary per montth of the peoplle working on this project: $S
$ per month
In additionn, the followin

ng risks shouldd be considereed for buildingg the new techhnology:
1)) In-house deeveloped technnology is not tested in the field.

f
2)) Issues/customer calls thaat might be gennerated from the
t field are unnknown.
3)) Developmeent of in-housse developed technology will w take x months
m and wee need to keeep the
product run
nning (with olld third party licensing
l technnology) duringg this period.
t in-house liicensing technnology: InHouuseCost IC= ∑ ((w*x) + (z*yy))*$S

Total Costt for building the
F
Figure 9: New
wly Developedd Module Repllacing Legacy Module Durinng Mid-Projecct Cycle.
Both thesee costs are then compared (TTC and IC) andd differentials are evaluatedd. The result, after
a considerinng the
identified risks, allowed
d and motivateed the Project Manager to gog ahead with developing ann in-house liceensing
technologyy.
The Figure 9 illustrates the project movement, where the third-party licensing module (A) is interacting with
the licensing database 8. While the project (legacy) is moving from one milestone to another (represented by
M1, M2, M3, M4), the team continuously developed the in-house licensing technology module (A’),
interacting with licensing database (B’). The legacy project was kept as client facing project with regular
prerelease and beta released to the field. The development of the in-house technology started in sprint 1 and
completed (including the testing) in sprint 3.
After sprint 3, as the in-house module was ready for deployment, we could phase out the third-party licensing
technology. The Integration team came into action and replaced module A with module A’. The licensing
technology database B was migrated to the licensing technology database B’. The transition was done
smoothly and from milestone 5 onwards, all users who were using the legacy project were given the newly
developed licensing technology module. The old third party licensing module helped the project running
successfully by keeping the licensing features intact during the first four milestones.
The above case study helps in understanding how RCM helps in sustaining a running project, removing a
legacy code from a project with a new in-house developed technology with a minimum down time. As per
RCM’s suggested approaches, multiple components in the above case study were developed in parallel (just
like multiple sides of the Rubik’s cube can be played by the user), component which is once complete and used
for customer demonstration etc was moved back from the project in order to support other component’s
development and deliveries. A direct interaction across component A’ and B’ was made and none of the other
project component was touched upon making sure retaining all necessary project interfaces. Processes and
Metrics, as core entities of RCM, also helped in setting up the project boundary limits, keeping the cost and
goals of project within control.
CONCLUSION:
The proposed Rubik’s Cube Model (RCM) provides interesting and helpful aspects of handling a software
project development by making an analogy to the way a Rubik’s cube object is operated upon. This model
covers features like parallel development of components, identifying logical groupings of components,
segregating components based on their dependencies on each other. Just like Rubik’s cube, this model enables
a project to deliver a working component even when rest of the components are not ready for a customer
facing delivery, just like one side of a Rubik’s cube (say “red” color side of the cube) can be completed
individually by a skilled player within a short period of time while rest of the side colors were still running
complete, in order to show a player’s capability. This model also discusses how a working component which
was declared once complete can be brought back out from the complete state to an in-development phase for
enabling other component’s delivery. This gets mapped to the playing skills of the Rubik’s cube player where
the “red” color side, which was once demonstrated to the audiences, is now rolled back into a not-yet-complete
state because the player is now trying completing other set of modules.
This is a proposed model and a project manager can try using this for planning the software development
activities effectively.
REFERENCES:
1. Boehm, B.W., and F.C. Belz, “Applying Process Programming to the Spiral Model.” Proc. Fourth
Software Process Workshop, IEEE, May 1988
2. Iivari, J., “A Hierarchical Spiral Model for the Software Process,” ACM Software Engineering Notes,
Jan. 1987, pp. 35-37.
3. B. W. Boehm. A spiral model of software development and enhancement. IEEE Computer, May 1988.
4. A. Cockburn, Agile Software Development, Addison Wesley, 2001.
5. P. Kruchten, The Rational Unified Process – An Introduction, Addison Wesley, 2000.
6. W. W. Royce, Managing the development of large software systems, IEEE Wescon, Aug. 1970,
reprinted in Proc. 9th Int. Conf. on Software Engineering (ICSE-9), 1987, IEEE/ACM, pp. 328-338.
7. Software Engineering Institute, The Capability Maturity Model for Software: Guidelines for
Improving the Software Process, Addison Wesley, 1995.
8. Jain, A. “Sprint Retrospective Checklist– Method and Mechanism for tracking Dev-QE goals”– 9th
International Software Testing Conference (STC), India, 2009.
9. Agile Manifesto [link]
10. Agile Alliance [link]
11. Agile Modeling Driven Development [AMDD]
12. Burn down chart [Link]
13. Pressman, Roger S. (2001). Software Engineering: A Practitioner's Approach, 5th ed. New York, NY:
McGraw-Hill.
Other reading references
1. V. R. Basili, Ed., Tutorial on Models and Metrics for Software Management and Engineering, IEEE
Press, 1980.
2. V. R. Basili and H. D. Rombach, The experience factory, The Encyclopedia of Software Engineering,
John-Wiley and Sons, 1994.
3. P. Jalote, CMM in Practice – Processes for Executing Software Projects at Infosys, SEI Series on
Software Engineering, Addison Wesley, 2000.
4. B. W. Boehm. Software engineering economics. Prentice Hall, Englewood Cliffs NJ, 1981.
5. K. Beck, Extreme Programming Explained, Addison Wesley, 2000.
ABOUT THE AUTHOR:
Ajay Jain has ten years of software industry experience, primarily in software project and program
management. He is currently working with Adobe Systems, Inc. as Quality Engineering Manager, leading and
managing multi million dollars projects covering Creative Suites validation. Prior to Adobe, Ajay Jain worked
with industry majors like Lucent Technologies (Bell Labs Development Center) and Skyworks, Inc, where his
experience ranged from building teams from scratch to scaling up to resource optimized, efficiency driven
teams handling multiple product lines.
Ajay has an active interest in knowledge sharing on industry best processes and practices and has multiple
publications in various internationally reputed conferences. Besides publications, Ajay serves in the Adobe
Quality Summit core organizing committee for 3 consecutive years. Ajay is also serving on technical
committee for international conferences like ICCAE’ 2011 (China) and ICRITO’2010 (India). He also has a
Patent Invention–Meritorious Disclosure Award to his credit.
Ajay holds a B. Tech degree from Delhi Institute of Technology and a specialized diploma in Business
Administration from the Institute of Management Technology, India.

Rubik's Cube Model of Software Engineering For Incremental and Legacy Projects

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Rubik's Cube Model of Software Engineering For Incremental and Legacy Projects

Uploaded by

Copyright:

Available Formats

JOURNAL OF COMPUTING, VOLUME 3, ISSUE 2, FEBRUARY 2011, ISSN 2151-9617

Royce do suggested looping back data

These steps or phases are logically Coding

The limitations associated with the Waterfall model are as follows:

In this model, the project is divided into

Figure 2: Sprint Modeling

Following are the salient interpretations and behavioral aspects of RCM:

The following section describes each of these aspects in detail.

The remaining two sides (1 and 5 in Figure 3) are

Metrics (5 in Figure 3) Figure 4: Rubik’s cube in two dimensions

It is not necessary for each component to interact with other components.

Figure 5: Communication using Intermediate Channel

Figure 6: Frequent Communication across Components

Multiple components can be developed and worked upon in parallel.

Each individual component can be broken into multiple logical sub-components

 Implicit vs. Explicit  Architecture  Programming  Test coverage

 Requirements capture process  Requirements (Implicit/ Explicit)

It is not always necessary to complete all modules in a specific sequence.

The sequence and state of developing component need not be fixed.

3) Third party contract/support (for each cycle) cost is $B.

The total cost for contin

ThirdPartyyCost TC= ∑ (N*$A + $B)

1)) Number off developers/teesters needed: w (number off people)

In additionn, the followin

1)) In-house deeveloped technnology is not tested in the field.

t in-house liicensing technnology: InHouuseCost IC= ∑ ((w*x) + (z*yy))*$S

You might also like

t in-house liicensing technnology: InHouuseCost IC= ∑ ((wx) + (zyy))*$S