Not Signed-In
Which clippings match 'Development Life Cycle' keyword pg.1 of 2
19 SEPTEMBER 2014

Agile Software Development: what we've learned at Forty

"The general idea behind Agile is that instead of arguing about the wording of a requirements document written three months earlier with little perspective into the current situation, it's often healthier to acknowledge that the project is going to be flexible and evolving, and put processes in place that allow it to be that way.

Barely over 200 words, that manifesto become the foundation for a movement that has changed the world of software development forever. Endless writing and speaking has explored the various ways the manifesto could be interpreted, and many specific frameworks and methodologies (such as Extreme Programming, Kanban, Lean, and Scrum) have been developed to formalize its principles. A whole 'Agile industry' has emerged, with successful companies offering tools, training, consulting, certification, and other products and services. The economic engine behind the Agile movement as a whole is massive. ...

On the surface, it seems like design and Agile should magically work together, but there are some underlying philosophical issues you have to wrestle with before figuring it out. Design is all about big–picture thinking: planning, strategy, working out all the details, thinking everything through, making it perfect, etc. (Eric Karjaluoto called it the 'masterpiece mentality.') Agile, on the other hand, is more often about doing the basics and saving details for later: iteration, minimum viable products, 'perfect is the enemy of done,' etc. Those two worlds don't blend smoothly together, at least at first. Agile developers can get frustrated with designers for over–thinking things ('Why can't they just let it go? We can get to that later.'), while the designers get discouraged by the perceived low standards of Agile developers ('Don't you want it to be good? Don't you want the user to be happy?').

In both cases, though, the problem comes from a misunderstanding of each other's perspectives (as problems often do). The designer isn't being obsessive, they're just trying to do right by the user. And the developer isn't being lazy, they're just following a process that actually gets things done with minimal navel–gazing. Both sides could learn some important lessons from each other."

(James Archer, Forty)

1

TAGS

agile development • agile model • agile modelling • agile software development • current situationdesign processdevelopment life cycle • development methodology • Eric Karjaluoto • evolving needseXtreme Programmingfacing unpredicted challengesflexible management methodology • flexible process • formalised principlesiterative approachiterative design processiterative developmentiterative processjust-in-time (JIT)Kanban • Lean (methodology) • management methodology • over-thinking • perfect is the enemy of done • requirements documents • saving details for later • scrum software development processsoftware developmentsoftware development methoduser experience design (UX)UX designwaterfall modelwhirlpool model

CONTRIBUTOR

Simon Perkins
18 JUNE 2014

Scrum: iterative and incremental agile software development

"Scrum is a management framework for incremental product development using one or more cross–functional, self–organizing teams of about seven people each. It provides a structure of roles, meetings, rules, and artifacts. Teams are responsible for creating and adapting their processes within this framework. Scrum uses fixed–length iterations, called Sprints, which are typically two weeks or 30 days long. Scrum teams attempt to build a potentially shippable (properly tested) product increment every iteration."

(Michael James)

1

2

3

TAGS

agile developmentagile modellingapplication development • close online collaboration • cross-functional teams • development life cycleface-to-face communicationfacing unpredicted challengesflexible management methodology • holistic process • incremental development • incremental product development • iterative approachiterative design processiterative developmentiterative processjust-in-time (JIT)management methodology • Michael James • physical co-location • product development methodology • product development strategy • project managementproject management method • requirements churn • return on investment (ROI)scrum software development processself-organising teamssoftware development method • sprints • whirlpool model

CONTRIBUTOR

Liam Birtles
08 JANUARY 2013

Concurrent Engineering versus Sequential Engineering

"Sequential engineering, also known as serial engineering, is characterized by downstream departments supplying information to design only after a product has already been designed, verified and prototyped [1], in order to change what design engineering did wrong, or what could have been improved. In serial engineering, the various functions such as design, manufacturing, and customer service are separated. The information in serial engineering flows in succession from phase to phase. For example, the prototype model, verified by either simulation or prototyping or both, is reviewed for manufacturing, quality and service. Usually, some changes are suggested after the review. If the suggested changes in the design are made, there are increases in the cost and time to develop the product, resulting in delays in marketing the product. If the changes cannot be made because of market pressure to launch the product quickly, or the fact that the design is already behind schedule, then specialists in other functional areas or managers from manufacturing, quality, and service, among others, are informed of the impending problems. In sequential engineering a department starts working only when the preceding one has finished, and, once a department has finished working on a project, or part of a project, this is not planned to come back: information flow is only one way.

On the contrary, in CE all functional areas are integrated within the design process. In this case information continuously flows back and forth among all functions. During the design process CE draws on various disciplines to trade-off parameters such as manufacturability, testability and serviceability, along with customer performance, size, weight, and cost [1-2]. The decision making process in a CE environment differs from sequential engineering in that at every stage decisions are taken considering the constraints and the objectives of all stages of the product life cycle, thus taking at the product design level issues that are usually addressed much later, thus giving the possibility to achieve a better overall solution [2,3]. The integration of other functional areas within the design process helps to discover hard to solve problems at the design stage. Thus, when the final design is verified, it is already manufacturable, testable, serviceable, and of high quality. The most distinguishing feature of CE is the multidisciplinary, cross-functional team approach. Product development costs range between 5% and 15% of total costs, but decisions taken at this stage affect 60–95% of total costs [4]. Therefore it is at the product development stage that the most relevant savings can be achieved."

(Ecehan SofuoÄŸlu, 2011)

Ecehan SofuoÄŸlu (2011). "Different Approaches to Concurrent Engineering"

1

TAGS

competitive capabilities • concurrent engineering (CE)cross-functional design teams • cross-functional team approach • decision making process • design engineeringdesign processdevelopment life cycle • downstream • engineering and manufacturing • functional areas • manufacturability • manufacturable • manufacturingmultidisciplinary teams • new product development • over-the-wall design processover-the-wall engineering • overall solution • product development • product development methods • product development stage • product-lifecycle • sequential engineering (SE) • sequential stages • serial engineering • serial prototyping • serviceability • serviceable • silos • successive phases • testability • testable

CONTRIBUTOR

Simon Perkins
17 DECEMBER 2012

Jim Conallen: iterative web application design and development

"If you are looking for a cookie–cutter recipe to success, forget it. Developing applications is hard work and relies heavily on the skill and the ability of everyone involved. Even so, a strong process is important. Heroic efforts on the part of a development team can often bring a project to maturity; however, heroic efforts and strong process can do so repeatedly and reliably."

(Jim Conallen, 2002)

Jim Conallen (2002). "Building Web Applications with UML", (Addison–Wesley Object–Technology Series).

1

TAGS

2002 • application design • application developmentconceptual model • cookie-cutter • development life cyclediagramiterative design processiterative developmentiterative process • Jim Conallen • methods for design practicemodelling language • page based web applications • page-based web applications • Philippe Kruchten • requirements gathering • SDLC • software design • Software Development Life Cycle • software modellingUMLUnified Modelling Languageweb applicationweb application designweb application development

CONTRIBUTOR

Simon Perkins
19 JANUARY 2011

Single-pass sequential 'waterfall' approach to software development

"I am going to describe my personal views about managing large software developments. I have had various assignments during the past nine years, mostly concerned with the development of software packages for spacecraft mission planning, commanding and post–flight analysis. In these assignments I have experienced different degrees of success with respect to arriving at an operational state, on–time, and within costs. I have become prejudiced by my experiences and I am going to relate some of these prejudices in this presentation. ...

A more grandiose approach to software development is illustrated in Figure 2. The analysis and coding steps are still in the picture, but they are preceded by two levels of requirements analysis, are separated by a program design step, and followed by a testing step. These additions are treated separately from analysis and coding because they are distinctly different in the way they are executed. They must be planned and staffed differently for best utilization of program resources."

(Winston Royce, 1970)

Figure 2 The "waterfall method" (one of numerous development models discussed by Royce in his seminal paper).

Winston Royce (1970). "Managing the Development of Large Software Systems", Proceedings of IEEE WESCON 26 (August): 1–9.

1

CONTRIBUTOR

Simon Perkins
Sign-In

Sign-In to Folksonomy

Can't access your account?

New to Folksonomy?

Sign-Up or learn more.