Potter Model - A Change Compliant Software Development Lifecycle Model

Varun Mittal Charu Chopra

Computer Science Researcher Computer Science Researcher JIIT, India JIIT, India

varunmittal87@gmail.com charu.chopra@gmail.com

Abstract - A software development life cycle model based on predicting and deciding maximum possible changes which can come in the time line of project completion has been proposed. The model makes it easy for developers to manage the constantly changing requirements and specifications. This model instead of focusing on people and resources focuses on architecture. It is not a replacement for Agile and other iterative models. It is addition of a new perspective of architecture to the existing software development life cycle methodologies.

Keywords – agile; architecture; Change management; iterative; pottery; scrum; SDLC; XP

I. INTRODUCTION

We have proposed an SDLC model which is focused on developing software architecture in such a way that maximum number of changes can be incorporated in the software. The focus is to design the application as a pottery artifact with appropriate support for increments and recreations in modules. Most of the existing models are unable to cater to real time problems, circumstances and situations faced by software developers. Our model shall work towards providing a better and more sustainable option to the software developers.

Proposal: A new SDLC model which is closer to the actual procedures followed in the practice and in industry. The models provides for changes in the user requirements are methods to handle them with a tolerance limit higher than all other SDLC models.

II. EXISTING APPROACHES

A. Waterfall model It is a linear process of collecting requirements, doing the

design, writing the code, testing and then maintaining the application. One of the basic tenets of the waterfall methodology is that each development phase has to be completed before the next phase begins. [15]

B. Spiral Model It combines elements of both design and prototyping-in-

stages, in an effort to combine advantages of top-down and bottom-up concepts. There are 4 main phases of the spiral model are Objective setting where Specific objectives for the project phase are identified; Risk assessment and reduction where-in Key risks are identified, analyzed and information is obtained to reduce these risks[3]. Then there is Development and Validation. During this phase an appropriate model is chosen for the next phase of development. It is followed by planning which consists of project review and plans are drawn up for the next round of spiral. [15]

C. Unified Process It is popular iterative process framework. There are

approximately 50 artifacts or work-products to be completed in UP. All this documentation and prescriptive approach adds a lot of ceremony to UP. Moreover, UP predefines roles to the project team making it bureaucratic and less flexible. The main tenets are Development in short iterations, Development of high risk and high value elements in early iterations, Delivery of value to the customer, Acceptance of change and Team Collaboration [15] [9]

D. V-Model The V-model is a software development process which can be

presumed to be the extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-model deploys a well-structured method in which each phase can be implemented by the detailed documentation of the previous phase. [5]Testing activities like test designing start at the beginning of the project well before coding and therefore saves a huge amount of the project time.

E. Agile 1) XP

The XP paradigm revolves around communication, simplicity, feedback, and courage. XP developers communicate with their customers [2]. They create a simple design. They get constant feed back by the continuous testing and integration of the software and from close rapport with the customer. Furthermore, with the above qualities in hand, XP programmers respond to changing environment with much more courage. XP team spends few minutes on programming, few minutes on project management, few minutes on design, few minutes on feedback, and few minutes on team building many times each day[4][5]

2) Scrum Scrum is an iterative, incremental process for

developing any product or managing any work. Scrum concentrates on how the team members should function in order to produce the system flexibility in a constantly changing environment.[6] At the end of every iteration it produces a potential set of functionality. Scrum does not require or provide any specific software development methods/practices to be used. Instead, it requires certain management practices and tools in different phases of Scrum to avoid the chaos by unpredictability and complexity [8].Ken Schwaber illustrates, “Most management is used to directing the project, telling the team what to do and then ensuring they do it. Scrum relies on self-organization, with the team deciding what to do while management runs interference and removes roadblocks” [9]

3) DSDM The DSDM has a set of ideologies. [5] Active user

involvement is imperative. DSDM teams must be empowered to make decisions and the focus is on frequent delivery of products. Fitness for business purpose is essential criterion for acceptance of deliverables. In this method, Iterative and incremental development is necessary to converge on an accurate business solution. As a matter of principle, all changes during development are reversible. A collaborative and co-operative approach between all stakeholders is essential. The base of requirements is set to a high initial level. Testing is integrated throughout the lifecycle.

DSDM is a concoction of Rapid Development and Iterative Development. Martin Fowler, who is one of the writers of Agile Manifesto, believes, “DSDM is notable for having much o f the infrastructure of more mature traditional methodologies, while following the principles of the agile methods approach” [2]

2011 Second International Conference on Intelligent Systems, Modelling and Simulation

978-0-7695-4336-9/11 $26.00 © 2011 IEEE

DOI 10.1109/ISMS.2011.22

66

2011 Second International Conference on Intelligent Systems, Modelling and Simulation

978-0-7695-4336-9/11 $26.00 © 2011 IEEE

DOI 10.1109/ISMS.2011.22

66

4) FDD Unlike the other methodologies, the FDD approach

does not cover the entire software development process but rather focuses on the design and building phases. It includes the following phases:

• Develop Overall Model • Build Feature List • Plan By Feature • Design By Feature • Build By Feature

The first three phases are done at the beginning of the project. The last two phases are the iterative part of the process which supports the agile development with quick adaptations to late changes in requirements and business needs. The FDD approach includes frequent and tangible deliverables, along with accurate monitoring of the progress of the report. Milestones that mark the progress made on each feature are defined to report and keep track of the software development project accurately. This section gives a high level overview of the activities.

5) ASD The core of ASD is the premise that outcomes are naturally

unpredictable and, therefore, planning is a paradox. It is not possible to plan successfully in a fast moving and unpredictable business environment. Adaptive development is essential when you have developers, customer, vendors, competitors and, stockholders all attempting to interact with one another at such a pace that linear cause and effect rules cannot assure success.

III. KNOWLEDGE GAP The existing models focus on evolutionary or iterative

development. The agile models focus on human aspect as SDLC model. Traditional software methods discourage learning and creativity as they plan everything in advance and then only require following the design. However in a highly volatile and turbulent environment where requirements change rapidly, adaptive software development is the key to success. This can only happen when individuals communicate in a rich way to deal with uncertainty and management fosters leadership and collaboration rather than encourage command-control doctrine. In an adaptive environment, learning challenges all stakeholders – developers and their customers – to examine their assumptions and to use the results of each development cycle to adapt to the next.

TABLE 1 DIFFERENCE BETWEEN THE AGILE AND ITERATIVE APPROACHES Our Approach Agile Methods Traditional methods

Approach Predicting the adaption possible

Adaptive Predictive

Main Success parameter Compliance with changes Business value Conformation to plan Project Size Any Size Small Large

Style Of Management Controlled Autonomy Decentralized[2] Autocratic Perspective to Change Change Embracing Change adaptability Change sustainability

Culture Every one is a leader Leadership-collaboration Command-control Documentation Low Low Heavy[8]

Emphasis Change oriented People-oriented Process-oriented Cycles Numerous Numerous Limited

Domain Expecting the unexpected Unpredictable/exploratory Predictable Upfront Planning Medium Minimal Comprehensive

ROI Over the life of project Early in project End of project Team size Small/ Visionary Small/creative Large

Primary objectives Change compliant architecture

Rapid value[5] High assurance

Requirements Constantly Changing Largely emergent, rapid change, unknown

Knowable early, largely stable

Size of teams Small Small Large Architecture Designed for maximum

possible future requirements[2]

Designed for current requirements

Designed for current and foreseeable requirements

Planning and control Internalized documented plans, stronger control

Internalized plans, qualitative control

Documented plans, quantitative control

Customers Concerned participative in setting maximum possible

requirements

Dedicated, knowledgeable, collaborated, collocated

onsite customers

As needed customer interactions, focused on contract provisions

Developers Focused, creative, collaborative, architecture

oriented

Agile, knowledgeable, collocated, and collaborative

Plan-oriented; adequate skills access to external knowledge

Refactoring Expensive Inexpensive Expensive Risk Prepared to face risks, high

preparation Unknown risks, Major

Impact Well understood risks, Minor impact

6767

IV. PROPOSAL

A. Pottery Model Software can be understood as a piece of pottery.

Software, like pottery is built from scratch and results in a highly sophisticated structure.

B. Detailed Analogy

1) Argument 1 - A pottery can be molded in whatever way it has to be before it is baked. Software can be molded in whatever way it has to be before it is coded

2) Argument 2 - Requirements Potter must know what kind of shape and features the

artifact should possess. Software engineer must know what features the software is expected to have.

3) Argument 3 - Changes Both Potter and s/w engineer detest changes in the

initial set of requirements C. Strategy

Potter makes provisions for increments in the non structural portions. Similar strategy can be adopted. Define a basic structure and then instill increments and then step by step

D. Keywords 1) Open ended architecture - Various components of any application can be classified under following heads – a) Database b) GUI c) Control Module(s) d) Interface Module(s)

What does the term open ended architecture means? Open ended architecture can be defined as an approach of

developing and finalizing the design of an application in a manner such that future addendums or increments are incorporated in the existing structural framework without disturbing the existing setup. The application skeleton provides for incorporation of new features and control flows keeping them synchronized with the existing framework. 2) Cavity: Internal part of application wherein all the processing takes place. It is analogous to the cavity in a pottery artifact where all storage actually takes place. 3) Buffer Zone: There shall be provision for keeping buffer zone in the application wherein two modules interact with each other either in terms of vertical or horizontal. • None of the modules interact with other module directly. • There shall be dummy interface or buffer layer which does the interaction. • As a result we don’t have to make changes unless extremely necessary in the modules. • Changes in interaction parameters, involving of other modules etc can all be then controlled through these buffer layer or classes. 4) Plugs - Those places in application which we think might have a feature or control flow origination from them in future shall be provided for in advance.

For Example - Provision for a few extra buttons on a screen. Though the buttons might be inactive and invisible for now but we should design the layout in such a manner that whole GUI is not required to be worked on again in case of introduction of a few buttons nor it loses its aesthetic sense when such provision and changes are made.

It might seem wastage of effort and resources (to some extent (Leaving expansion space between the vertical and horizontal edges of modules).We believe that client may request some or other feature at a later point of time.

Our architecture supports such changes to the extent that the basic structure is not violated. This is a remarkable improvement over existing models which don’t provide for issues and constraints encountered in real application development and requirement fluctuations.

V. SUPPORT FOR EXISTING APPROACHES

A. Support for OOPs Architecture The model provides for a special provision called CASTS. Several

times off the shelf components are used in applications. Such components belong to two categories

1) Components created by the group itself • Same team other project • Other team similar project • Company repository

2) Components sourced from outside • Free • Paid The model provides for including such components in the scheme

of planning. It also reinforces and builds upon the principle of “reusability” which is a pillar of OOP’s architecture.

Analogy: Potters use casts to make the regularly used parts required in artifacts. In this way they save on their efforts and over a period of time posses a repository of easy to make components. This apart from making their ventures economical more sound also provide scope for utilizing their time in pursuing creative or other challenging tasks. We seek to deploy the strategy in the SDLC as well.

B. Support for AGILE methods The agile methods focus on the developer and the way they work

while the proposed approach focuses on the software and how it can be developed so as to make it for responsive and inclusive for dealing with the same issue – changing/changed user demands. Both the approaches are not competing with each other but are supporting each other to deliver the highest cost to affect ratio. The proposed mechanism can work in tandem with by abiding by the basic values of certain agile models:

1) XP TABLE 2 – SUPPORT FOR AGILE

Communication

The communication in XP is extremely fast and is unaffected by hierarchies. The practices like pair programming ensure that communication is impartial. The time lag between the recording of event and reporting is one of the least among all other process approaches.

Simplicity Extreme Programming starts with the simplest solution. More functionality can then be added later. Experts of XP acknowledge that this can sometimes call for more effort tomorrow to change the system and it is supported by the advantage of not investing in possible future requirements that might change before they become relevant. Coding and designing for uncertain future requirements could mean using resources on something that might not be needed at all.

Feedback Feedback from the system: by writing unit tests [1] or running periodic integration tests, the programmers have direct feedback from the system functioning after implementing changes. Feedback from the customer: The functional tests (aka acceptance tests)[9] are written by the customer and the testers. They give a well judged feedback about the current state of the system under development. This review is planned once in every 15-20 days so the customer can easily steer and review the development. Feedback from the team: if during the course of the iteration, customers come up with new requirements

6868

in the planning game the team directly gives an estimation of the time that it will take to implement

Courage Several practices embody courage. One is the commandment to always design and code for today and not for tomorrow. This is an effort to avoid getting bogged down in design and requiring a lot of effort to implement anything else. Courage enables developers to feel comfortable with refactoring their code when necessary [1][2] This means reviewing the existing system and modifying it so that future changes can be implemented more easily. Another example of courage is the ability to decide when to throw code away: courage to remove source code that is obsolete, no matter how much effort was used to create that source code. Also, courage means persistence: A programmer might be stuck on a complex problem for an entire day, then solve the problem quickly the next day, if only they are persistent.

Respect The respect value manifests in several ways. In Extreme Programming, team members respect each other because programmers should never commit changes that break compilation, that make existing unit-tests fail, or that otherwise delay the work of their peers. Members respect their work by always striving for high quality and seeking for the best design for the solution at hand through refactoring.

2) Scrum TABLE 3 – SUPPORT FOR SCRUM

Commitment

Scrum workers must be willing to commit to a goal, [6]Support & encourage commitment and The team has the authority to decide how to do the work it has selected

Courage Scrum teams must have the courage to commit, [7] to act, to be open, and to expect respect. It requires courage to act differently; and to find out that the environment will support these values; they should be to be willing to find out that relying on one’s own judgment is acceptable – even admirable

Respect In a scrum team, Individuals are shaped by their background and their experiences. There is Respect for different people who comprise a team. The team adjusts and adapts to meet its commitments for a Sprint:[3] (1) Who does what is up to the team(2) The team commits as a whole and sinks or swims together

Openness In scrum, it’s imperative to Keep everything about the project visible to everyone as it removes the ability to dissemble. Responsibilities are clear, authority is allocated, and everything is visible. Scrum counters interference by not allowing work to be added to a Sprint once it is underway

Focus Focus is on doing your job and all your efforts and skills must be focused on doing the work that you’ve committed to doing

VI. Validations and improvements over existing approaches

Problem: Decision of client requirement which would lead to

addition of some data fields in some table(s). We can’t directly add those attributes in the table as in that case all earlier prior data rows will place a null value in the corresponding location of new attributes. This shall make the database inconsistent.

Strategy: In the database design there shall be separate keys for all sorts of tables which have the remotest probability of being modified at a later date. Keeping separate keys for all fields and creating corresponding mapping tables is instrumental in realizing our aim.

Solution: Make another table P with new key and the new added attributes .A mapping table between the previous tables (we call it E) and P is then made. In the way all new rows in E shall have the ability to store the added attributes as well through P while the prior rows circumvent the null values inconsistency. This can’t also be implemented by keeping the id of P as a foreign key in E because the older data is still present in P and it is inefficient to have the queries being made on two tables and nor can we create null variable filled rows in E. Hence the importance and utility of mapping tables is reiterated in such a scenario.

Our strategy proposes for such mechanisms to be put in place for all other components of the application as well.

TABLE 4 – DIVISION OF MODULES

Modules Layer Based division of modules

Segment Based division of modules

GUI User rights ( different kind of screens) General screens Developer screens Dummy screens

Aesthetics, color, resolution, size, resource requirement

Database Client Side Server side Middle ware

Data tables Lookup tables Extension tables

Processing Direct Indirect

Customized routers Generic Routers

Inter-communication

One way communications Two way communications Multiple communications

Customized communication Generic communication

A. Data tables: The tables which comprise of the actual data

which is stored and is required to be retrieved.

B. Lookup Tables: These tables comprise of keys and reference values which are used to access the data from the data tables.

C. Integration: These tables are the tables which are provided

to extend the data fields in tables or otherwise by means of managing them the alteration in collaboration with the lookup tables.

D. Horizontal Integration: It will be integration and

assimilation of all the modules of particular kind so to enforce homogeneity, ease of testing, maintenance updating.

6969

E. Vertical Integration: It will be integration of all the

modules related a part of the application wherein all of them constitute the module. For e.g. Screens, database, interconnection classes. Let us take example of a site of a shopping mart as a case

study. Various modules of such a site will be shopping cart, manual, contact zone, Herein Horizontal Integration will be among all the screens of the website in one stage, all database tables in other, connections with other sites in another stage, all mail server related tasks in yet another stage. As a result any platform change or such generic issues regarding a particular class of application components can be addressed more effectively.

Vertical Integration will be among the entire shopping cart - screens, database, paypal connectivity, credit card validation, receipt generation. In this way when in future any changes are made they will be made in the shopping cart, they are done here only and thus can be affected, tested and managed easily.

VII. CONCLUSION

We were able to propose the Potter model and link it with all the existing approaches. The proposed model brings on one platform all the existing methodologies. The strengthened unified approach takes into account people, process and architecture. We have deployed the model in the final year projects of the author and co author. We are able to generate higher level of competencies and effectiveness. The proposed approach was found to be extremely suitable in case where software building started with a concept and progressed with the evolution of theme.

REFERENCES

[1] D. E. Avison , G. Fitzgerald, Information Systems Development: Methodologies, Techniques, and Tools, McGraw-Hill Higher Education, 1998 [2] Ambler, S. Agile Modeling: The Official Agile Modeling (AM) Site. http://www.agilemodeling.com. [3] AOYAMA, M. WEB-BASED AGILE SOFTWARE

DEVELOPMENT. IEEE SOFTWARE, NOVEMBER/DECEMBER 1998. [4] Auer, K., Miller, R. Extreme Programming Applied. Addison-Wesley, 2002. [5] Basili, V., Rombach, D. Support for comprehensive reuse. Department of Computer Science, University of Maryland at College Park, UMIACS-TR-91-23, CSTR- 2606, 1991. [6] Beck, K. Extreme Programming Explained. Addison- Wesley, 1999 [7] Beck, K., Fowler, M. Planning Extreme Programming Addison-Wesley, 2000 [8] Cockburn, A. Agile Software Development. Addison- Wesley, 2002. [9] Cusumano, M., Yoffie, D. Software Development on Internet Time. IEEE Computer, October 1999. [10] Fowler, M. Refactoring. Addison-Wesley, 1999 [11] Fraser et al. Hacker or Hero? - Extreme Programming Today. OOPSLA 2000 Companion, Proceedings of the 2000 ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA 2000), Mineapolis, MN, USA, 2000. [12] Larman, C. Applying UML and Patterns. Second Edition, Prentice-Hall, 2001.

[13] Rising, L., & Janoff, N. The Scrum Software Development Process for Small Teams. IEEE Software, July/August 2000. [14] Schwaber, K., Beedle, M. Agile Software Development with Scrum. Prentice Hall, New Jersey, 2001. [15] Turk, D., France, R., Rumpe, B. Agile Software Processes: Principles, Assumptions and Limitations. Technical Report. Colorado State University, 2002

7070