This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
From the contents of your book, i assume that it covers how to fix the problems on the project, or how to avoid common mistakes in running the project. So this book doesn't explain the whole Software Development Life Cycle (SDLC) from end to end. Am I right?
So this book doesn't explain the whole Software Development Life Cycle (SDLC) from end to end. Am I right?
You are correct. Here's a quote from the Introduction
People and requirements gathering are two areas that we didn�t include. Good people trump tools, techniques, and process as the most important part of a project; however, assembling and keeping a great team is a subject worthy of its own book (or a series of books!). Instead, we focus on ways to leverage and grow the skills your team already has.
Similarly, learning about product requirements is another deep subject. There are many ways to collect requirements, ranging from note cards to complicated systems full of checks and balances. Rather than attempt to address another large issue that we couldn�t do justice to in a single chapter, we chose to present ideas that are flexible enough to handle changing requirements, no matter where you get the requirements from. The ideas in this book can accommodate the project whose requirements never change as well as the project whose requirements are constantly shifting. So you can use these ideas whether you get your requirements list from a small stack of 3x5 cards or a 10,000- page contract.
We�ve tried to keep the discussions generic enough that you can use them in any shop and with any technology. That�s why we didn�t add sections on installer technologies or code optimizing tools.
Check out <b>Ship It! A Practical Guide to Shipping Software</b><br /> <br /><a href="http://www.pragmaticprogrammer.com/titles/prj/" target="_blank" rel="nofollow">http://www.pragmaticprogrammer.com/titles/prj/</a>
A problem with the concept of "full SDLC" is that fullness is in the eye of the beholder. Also, SDLC is a loaded term because it includes the word development. For example, if you're interested in the full system lifecycle you should consider pre-development (e.g. portfolio management stuff), development, production, and even retirement of the system. What if you're interested in the full IT lifecycle instead? This would include the lifecycles of many systems, and would address cross project issues such as enterprise architecture, reuse, and administration.
Thanks for your correction about my the point of view of SDLC. Now i realize that the SDLC is not only dealing with the software, but also other system.
I have been working as a professional for 2 years now. The first 6 months i worked as a Software Tester/Quality Assurance for an ongoing project. After that i requested to be a developer in the same project. And until now the project is almost close. So for 2 years of my working experience, i haven't quite in even a single project life cycle at all And I'm interesting to extend my experience to taste all the process in the development live cicle. cos sometime I'm hoping to be a consultant like you Scott What would you suggest me to do? request to be a software analyse on the next project?
(Though you question is to Scott, I would like to share my experience / view with you too.)
Sound like to me that you have been working as a team member of project, either as a tester or developer. On being a consultant, I think experience is quite imnportant. There are cases that we have never met before, but in most case, it is our experience that can help. Besides, we need to consider what is other people's view on a certain consultant. Sometimes, I believe we can get different feedback even if the same statement made by two consultant.
Try to get more experience, get some chances in managing people (say coaching / leading other more junior developers or programmers).... and make yourself a team lead.... this may be a good way to pave the way.
Tony, I agree with you.. the most important thing for me right now is experiences and i'm looking forward for it in the next project that i will be assigned to. Like you suggested, I wish i could get the promotion to be a team leader! And I also hope it's a brand new project, so I can be involved from the start.. requirement gathering maybe..