We’re born, we grow, we have children, we die, and our children repeat the cycle, and the cycle repeats over and over again; thus, that’s the circle of life (Lion king music in the background). So we reach the final chapter of this awesome series where I and my gorgeous way of writing, told you bedtime stories about software development and the staged delivery method.
As everything begins, it must certainly end, and as well as this series of blogs, once you have survived and succeeded on delivering your project to your client, it’s time for you to gather the pieces of your exhausted, but triumphant team, and start gathering the experience that will make your personnel grow and future projects easier.
After the storm has calmed you need to make some question to your team on what they think it worked well, and what would they like to be changed. This might be a subjective impression, but it’s very important to take it into consideration, not only for keeping your team happy but they might be right and you might not notice. Do it quick, cause the most recent impression is what counts.
Review meeting: this method is good for having a continuous discussion and debate of the different ideas and opinions. Maybe someone is right, maybe they had a wrong view of the problem and change their mind. The important thing is to listen carefully and have a good moderator so that everyone’s point of view is heard.
Review Questionnaire: another good, and more individual oriented reflexional, method is a questionnaire. This can be sent by e-mail and the data can be stored electronically and used for analysis later. This method can use a more specific approach through certain target
There’s something in videogames that sadly life doesn’t have, that’s called a checkpoint. That’s right, that beautiful part of the game where a weird icon appears, normally in a corner of a screen, that indicates 2 things. The first one is that something that will make your progress more difficult is about to happen, and second, that you’ll probably die a lot of times and that it’s a good planning point to rethink your courses of action and strategies in the case of it. Videogames give you an infinite amount of chances to learn from your mistakes, maybe polish a strategy or change your view entirely. Sadly, life is not as good guy as videogames are. Life doesn’t give you a second chance to repeat a scene or a moment, if you did wrong, you did wrong, and you can’t keep on repeating until you get it right. Time is linear and the only thing you can do is get the fullest of the experience, learn and try to not make the same mistakes in similar, yet not equal, situations.
Nevertheless, what life does allow us is to take a certain amount of time to meditate our course of action. It’s not that of a douchebag that will keep enemies spawning and not giving any armor. No, life is comprehensive to a certain point, and in the stage delivery method, each end of stage is a good “checkpoint” to meditate our agains and never-agains so that we don’t keep repeating the same errors over and over again. Thank you not so douchebag life.
Propose changes and recalibrate estimates
The end-of-stage wrap-up is a good moment to speak up. If you would like to propose a change in the process or aggregate a certain feature there’s no
Imagine yourself at a bar, there’s a beautiful/handsome girl/guy and you want to conquer her/his heart with your sparkling personality, but he/she is surrounded by his/her hideous friends that won’t let you get nearby. You need someone to help you take the target friends far away, to create a distraction and give you the opportunity you’ve been mourning for. That angel in disguise is called a wingman (either men or women are called like that… I think). He creates the distraction you need in order to get close to your target and whether you achieve or not your goal it’s up to you, but you can’t deny you got all the support that you needed, and you know who also need a lot of support to achieve the quality desired in the code they’re developing? Developers of course, and you know who are their wingmen? Testers.
Testing and why is important?
Sometimes you’re so drunk in love by your own creation that you can’t see all the errors and defects it has. Sometimes you just need that outsider look that gives you objective feedback, and that is the testers job. In order to achieve the desired quality for the project, and for it to accept and integrate more code there needs to be a certain testing process that assures that quality and that can guarantee that the code won’t break with further integration of more code. This can earn a lot of debugging hours in the integration testing, because if it unit is correctly tested, then you can be sure that the only thing you need to test is integration problems and not unit problems. Your schedule and budget will thank you later.
In the middle of the war there’s no time for hesitation, there need to be quick actions and quick responses to enemy retaliation and the mission of the ruler is to stay calm and lead his army to victory. One famous phrase, and so ancient as well, is the rule of divide and conquer. This rule states that in order to achieve victory, it can be applied to war, politics and sociology; you need to divide the intended group, either a government or an army, into smaller more manageable groups in order to strike. Is easier to carry pieces of a rock than a huge block as well as killing a man is easier than a group of 20.
Applying this approach to software development it’s time to start analyzing how to break our project into manageable stages, and how to break those stages into even smaller parts called miniature milestone, and breaking THOSE MINIATURE MILESTONES INTO EVEN MORE, wait… that’s it, miniature milestones Is the atomic part. Well let’s see how to do it.
Stage planning and its parts
I know by this time around you’re absolutely tired of the word planning, but I swear that it’s something absolutely necessary. Please believe me! As I was saying, the beginning of each stage is about planning a detailed course of action; there needs to be and individual stage plan describing how to conduct individual design, coding, technical review, testing, integration and other needed activities. The most difficult part is to divide each stage into miniature deliverable milestones that help you track the progress of completion of each stage and the visibility status.
Stage delivery means turning a big project into little, more manageable projects, and each stage cycle being a mini project needs to be
There’s a certain calm that you experience when something is going to go inevitably wrong. The animals are silent, there’s no air waving, people stay inside their houses and the environment feels obscure and heavy. Some people say that this is the calm before the storm, before everything and everyone is violently threatened, and you need to put into test all the surviving skills that you learned in this blog. But, you still have time to prepare and grab any tool or resources that you might’ve forgotten. These are the final preparations.
Creating Project Estimates
After the quality and change boards are set, the preliminary planning has been done, the requirements have been stablished and the architecture designed, it’s time to start taking a guess on how much time, money and staff is going to be needed to achieve the project at hand. You need to have a good estimate in order to ask sufficient resources and the books suggests a series of rules of thumb to take into consideration while estimating.
It’s possible to estimate software projects accurately so stay calm.
Accurate estimates take time.
Accurate estimates take a quantitative approach, preferably one supported by a software estimation tool.
The most accurate estimates are based on data from projects completed by the same company that’s making this project
Estimates require refinement as the project progresses.
Keep this rules as mantras because the estimation process could be a stressful one in certain steps are not taken into consideration, but good guy McConnell gives us a guideline so that we don’t stress ourselves to much. He says the following:
The estimation procedure should be written.
Estimation should include time for all normal activities (even sick days).
The project plan should not assume the team will work overtime.
First there is the concept and then comes the sketching. That’s the process of every great masterpiece in this world. The artists can’t sleep, he has something up in his mind that doesn’t let him reconcile sleep. Then comes the divine illumination, where the artist knows exactly what he wants and need to sketch it, pull it aside his turbulent thoughts. At the end, comes the masterpiece, the expression of the idea, the peak of the creativity… the masterpiece. We’re not quite to the part of the masterpiece yet, but the architecture is the sketching part, let us talk about it.
What is Architecture?
The architecture is the technical structure of the project at glance. If you want to make the rest of the project easy, you want a good architecture, else please mess up this part, you’ll sure regret it. Or maybe this is one of those times we’re people who love terrible news, receive good news, am I right? Nevertheless, this is the blueprint part before the construction. In software development, we refer to the blueprint part as the phase where we describe the software with diagrams and prototypes, so that the developers get the general idea of what to code.
During this phase, the architecture special task team, sounds cool, divides the system into little subsystems, specify the interaction among them and document the technical plan of the software at a top-level. They also specify the correct approach to handle errors, memory specifications and technical overviews. This will help conceive, in a more smoothly manner, the integrity of the conceptual part in future stages
Characteristics of a good architecture
What makes a good architecture? How can we be sure we’re not drawing doodles instead of The Mona Lisa? Deep into the design the
Don’t you get this unknow urge to clean something? Can’t you stand seeing your bed dirty? Do you fill like they will tear your insides when people chew with their mouth open? Is it necessary to turn the light off and on 24 times before leaving your house? Will you kill everyone at your office because of inferior quality software? If your answer was yes to only the last of those questions then this blog post is for you, and you’re cut to do the job I will describe here. If you said yes to any other questions please go right away to your nearest psychiatrist.
Why quality matters?
Quality in the software development word can be confused with testing exclusively. If it doesn’t crash then is good to go, but that is not necessarily the case. Good quality software encompasses many things such as clear and understandable code that can be documented or reused in future projects, that it’s scalable, trustworthy and obviously that it satisfies the implied and stated requirements without burdening the end user. So, quality mean good for the developer, good for the system and good for the user, and having a good control on quality will help detect bugus code that can lead to risks in future stages that will create big economic damages to the project. Then how can we achieve that such quality levels?
Quality assurance plan
You need to set your own standards of quality and everyone should commit to them. If any of the project parts, either documents or software modules do not comply with these standards the project should not be allowed to continue until these issues had been addressed and everyone should be ok with it. Some of the elements involved in this plan are the
Sometimes we are lost in life. We are not sure of the path we need to choose. Is this the right door? How do I know if I go this way I’ll not close a very precious path? Will I regret it on the future? Sometimes these fears won’t let use even move and in the end, we choose not to choose, which ironically is a choice. But how to we fight these nonsenses? Well I’m a true believer that the right path is chosen based on knowledge and wisdom, and to achieve those we need to experience more things in life and make ourselves more questions, even though sometime the experience will be learnt through harsh leaving experiences and may be not what we want, but it’s what we need.
Applying these beautiful words of wisdom, that come from the deep blackholes of my mind, into software development, to choose the right path we need to ask the right questions or have leaved lots of similar projects. Unfortunately, most of your clients will be different, and will come with needs that are very different each and every time, due to the constant change in the software industry. That’s why the only way to cut our way through is by engineering into their minds and capturing the right… wait for it… requirements. Thank you.
Software requirements refers to stablishing the needs that the stakeholder wants to solve through the software project, and requirement development refers to the processes that are to be done in order to find those needs.
The requirement development stage is extremely important because from here on the foundation of the project will be defined. The architecture, the design, schedule, personnel, discovery phase and almost the product vision is defined in this