This volume is about what you did during the project it’s exactly what is says, history, the history of how you develop your project, this is useful for future projects because it is written to know in what you were stuck and how not to repeat that in the future.
Whether the project has been an awesome success or an awful failure, it was also a time to learn from what you experienced during that project and for the future to build a foundation for future successes.
You can also have project review meetings that can be valuable times for project members to discuss their insights candidly because everyone has a perspective on how the project outcome at the end, and those insights can be tremendously beneficial to the organization or future projects on the organization or in an individual way.
Here are some do’s and don’ts for developing a project from NASA, enjoy.
· Empower project personnel
· Minimize the bureaucracy
· Define the requirements baseline, and manage changes to it
· Take periodic snapshots of project health and progress, and replan when necessary
· Re-estimate system size, effort, and schedules periodically
· Define and manage phase transitions
· Foster a team spirit
· Start the project with a small senior staff
· Don't let team members work in an unsystematic way
· Don't set unreasonable goals
· Don't implement changes without assessing their impact and obtaining approval of the change board
· Don't gold-plate
· Don't overstaff, especially early in the project
· Don't assume that a schedule slip in the middle of a phase will be made up later
· Don't relax standards in order to cut costs or shorten a schedule
This volume is about the stage planning these maps out a detailed course of action for each stage. Each stage in a project is like a miniature planning, this means that in each stage there is planning, design, construction, testing, and preparation for release. Software developers noticed that each stage is like a small project, that means that if you finish a stage (small project) is less risky to fail than a big project, but hey, at the end is finally the big project you’re making so yeah, mind-blowing.
Now I’m going to explain the stage planning activities, so yeah, as I told you in past blogs, planning is the key of success it makes everything easier, so let’s start…
· Requirements updates, this are the same you specified during prototyping and requirements development the difference here is that you evaluate possible changes to requirements.
· Detailed design supports the software construction that will be done during the stage.
· Construction is when the developers code the software to be delivered during the stage.
· Test case creation is when testers create the full set of test cases needed to test the functionality developed during the stage this can be done while construction is being develop.
· User documentation updates is the User Manual/Requirements Specification that updates to describe the as built software.
· Technical reviews are when developers participate in design and code reviews.
· Defect corrections are when developers correct the defects uncovered by testing and reviews.
· Technical coordination is when managers of large projects coordinate the activities of different groups of developers.
· Risk management is when the project manager review the project's current Top 10 Risks List.
This chapter is about the final preparations of planning, so here I go, explaining that the team is ready to finally create its first estimates, develop a plan to deliver the project.
Describes the preparation work that should be done after the project requirements have been baselined and architecture work is under way. This work includes the following tasks:
In the project estimates the requirements are finally been baselined, now it’s the time to create meaningful estimates for effort, cost, and schedule, keep in mind that the estimation procedure should be written, estimates should include time for all normal activities, the project plan should not assume the team will work overtime, estimates should be created using estimation software, estimates should be based on data from completed projects, watch for estimates that developers don't accept, the project team should plan to re-estimate at several specific times during the project, estimates should be placed under change control.
Writing a Staged Delivery Plan, the software is ultimately delivered in stages, with the most important functionality delivered first, this means in this order Software concept, requirements development, architectural design, Stage 1 to n: Detailed design, construction, and release and finally software release.
Performing ongoing planning activities explicit risk-management activities that were initiated at the beginning of the project should continue throughout the project. Check the vision statement and, if necessary, revise it so that it can provide direction throughout stage planning, architecture, and detailed design and implementation. Check whether the decision-making authority identified during preliminary planning is clear about the project plans and goals, including the Change Control Plan and preliminary estimates.
This chapter is about the software architecture which provides the technical structure for a project. If the architecture is good makes the rest of the project ready but if it is a bad architecture the project will be impossible to develop so here we have another important fact that should be take care of, the wonderful architecture.
The architecture phase in software development is a time during which the software is mapped out using prototypes and design diagrams, it also provides an exploring feature that search for types of low cost, the architecture team partitions the system in subsystems to specify the interactions between them, it also address the major design issues that appear throughout the system such as memory management, string storage and error handling.
Architecture must support the delivery plan and the architecture document. For the delivery plan, it must accommodate functionality to each piece of a delivery, and for the architecture document it should describe all the architecture process. The architecture plan won’t stop, but it should be committed to put the conceptual into real with its analyze requirements working perfectly.
In conclusion architecture is an essential phase so the project has the correct construction is like the base of it because is part of the design, If it is not well designed, it will not work for what was intended to do.
This chapter is about the quality assurance this is testing but now it’s not only that it’s also about technical reviewing and project planning. The general definition of quality is "the degree to which the software satisfies both stated and implied requirements." In fact, this chapter explained how to assure that kind of quality.
Why quality is important? Well, software quality has a bottom-line impact on the costs of doing business, so that is the main reason. Low quality software increases the burden on end-user support. Leading-edge companies by charging end-user support costs back to the business unit that produced the software responsible for the support call.
It is also important what you decide because the effect of releasing low quality software will cause an effect on your business. Normally, customers do not remember that high-quality software was delivered late or that low quality software was delivered on time as much as they remember whether they like using the software.
An effective quality assurance plan will call for several quality assurance activities, that I’ll explain in an easier way:
·Defect tracking is the activity of recording the defects from the time they are detected until the time they’re resolved. They can be detected and resolved in both levels individual and statistical
·Unit testing is informal testing of source code, is usually performed informally but should be required for each unit before that unit is integrated with the master sources or turned over for independent review or testing.
·Source-code tracing is stepping through clearly the source code line by line in an interactive debugger that are many. This work is usually performed by the developer who wrote the code, but it can be a Continue reading "#TI2011 #ChapterNine"→
This chapter is about requirements and the importance of knowing perfectly what the project need to fulfil its creation so this part is essential to the success of it.
The development of requirements is divided in three parts:
·Candidate requirements, this is done by interviewing the client questions to make sure that him and you are in the same page.
·Specifying requirements this is done by committing the candidate requirements to a tangible media, and not just words, because writing in paper make those things clear in your head, you must check and make him sign what you talked and write is what the client wants.
·Analyze requirements is breaking down the essential characteristics
When the author said, “I use the word development to emphasize that requirements work is usually not as simple as writing down what key users want the software to do.” Is brilliant, because this is a step that many people that is new in developing software skip and they just write and write what the client says and that’s not the correct way, you must analyze and say to the client if his idea will work and how you will implement it so he knows what can be done.
SPECIFYING requirements is so important for further development and specially in coding, because you will take 50-200 of time correcting the requirements, so please, make sure that your requirements are ready to be code.
The author give us nine steps to develop requirements that I would break down in an easy way.
1.Identify a set of users who will provide the guide lines in the project’s software requirements define.
Esto es un resumen de lo que logré adquirir de la conferencia de Ricardo Rodríguez Fernández uno de los muchos presentadores que Ken nos ha traido
¿Cómo ciertos grupos llegan al éxito? Característica, los que llegan al objetivo es los que están a favor/buscando algo y no en contra lo negativo no prospera, esto tiene relación con los equipos de Software
Cuatro factores principales/ Los Pilares
Objetivo claro, puedes hacer un mapa
Propositivo que sea de ideas, serie de personas que dicen que no va a funcionar (fracaso)
Equipos exitosos tienen un plan, los planes no sirven en la ejecución para nada, pero si no planeas fracasas ya que no sabes que hacer
Los equipos exitosos tienen compañerismo, apoyo es fundamental
Objetivo en un programa de Software
Software exitoso = Software utilizado
Para que usen tu software tiene que ser consistente
A pesar de errores el software debe de ser consistente a menos que sea erróneo
Imposible llegar al 100 en un software
La consistencia es el factor principal para mantener a un cliente satisfecho
Crear un producto que entregue valor y por el que estén tus clientes dispuestos a pagar
“If you’re not embarrassed by the first version of your product you’ve launched too late” – Reid Hoffman
El software se vuelve bueno con el tiempo, el software es iterativo, no tardar tanto en desarrollo
You are confined only by the walls you build yourself
Ser objetivo, aterrizar las ideas y dejar las cosas que no te pidieron pero que pueden funcionar para parte de actualizaciones que sean cosas que el usuario en verdad las vaya a usar sino son extras inservibles.
No existe el requerimiento estable los requerimientos son dinámicos.
This chapter is about planning plans for plans to have plans correctly planned, I did this so you are aware that the objective of this course is totally about planning so you can have a nice and less stressful project, so here we go.
The first thing about any project is to have a vision and more than that a common vision, without a shared vision high performance teamwork can’t take off. Studies mark that having a clear objective the team function in an effective way, helps to decision making on smaller issues, helps to keep the team focused and avoid time-wasting side trips and many other things, so have a common vision to make an effective project. To define what to leave out is linked to the vision so it must be precise so it can guide the project to an easy way to develop and knowing what is going into the project and what won’t.
The executive sponsorship is the support given to the group who has the final decision, this is critical to project success, this group should be responsible for committing to a feature set, approving the user interface design, and deciding whether the software is ready to release to its users or customers. When I think of the executive sponsorship I remember of a conference that we had in Ken’s class that is about having one person that says go ahead with that or not and is the CEO, so for every final decision it goes right to the CEO’s hands to decide.
The project scope targets are having an idea about the intended budget, schedule, staffing, and feature set of the software at the end all of them are estimates, it’s rarely that a project Continue reading "#TI2011 #ChapterSeven"→
This time I’m bringing to you about how to manage the changes correctly in a very efficient control without making an expensive investment in them because controlling changes is an integral part of the project planning and is critical to project success.
The procedure to control changes in a project is at first in the initial development work, here the changes are made in a free way to the work product, in second place the work product is submitted to technical review and declare complete, in third place we send the work product to the “change board” which in here we make changes in a more systematic process, in fourth place it is send to revision control where everything you do is checked to find things that can change, in the fifth and final place is explained the process of a change, at first the proposal change is sent, then the change board identifies what is affected by the new proposal change and notify, the next step that is assess the cost and benefits of the proposal change, then is to accept or reject the proposal change and finally notify if the change proposal will or won’t proceed.
Change control primary benefit is that it does what is intended to do, another thing it does is that it protects the project from unnecessary changes by ensuring that the changes proposal is considered by a systematic way as we talk the last paragraph, it also improves the quality of decisions making every parties involved in them. The change control is aware of everything when something is “finished” it reviews and check if the work product or the reached milestone is complete.
I hope this chapter is as cool as I think, let’s start and you’ll know my answer in the next lines of how amazing it was…
Yep, it was awesome, let’s start step by step what impact the chapter created in me.
In the intellectual phases, we have three, the first one is discovery that is characterized of converting uncertainty to certainty through investigation, such as knowing what the user, customer, client want and creating user interfaces, the second phase is the invention like the discovery phase only that things that couldn’t be certain in discovery they are at invention and finally the third, implementation it focused on realizing what is certain by the other two phases.
At each stage of implementation, the group task release functional product in each stage delivery is provide several important benefits, like critical functionality, reduced risks, evident problems, reduced status-reporting, more options, reduces possibility of error, balances flexibility and efficiency.
The disadvantage of each stage is that everything is repeated so each action for each stage cost more, but is so minimum that the cost is worth it against doing it all again because there was a mistake at downstream that will cost more than doing it by each stage.
In this chapter I learned that completing stages is better than doing each part alone, that would be all for now, until the next one.