Information stored in a project’s software project history document will be useful to future projects. The software project history uses data from the software project log, wich is updated at the end of each stage; the project history distills general lessons from that data. On well-run projects, most of the data needed for the software project history will be readily available and the project history will be easy to create.
Some project review meeting at the end of the project. Other collect e mail summaries of what each proyect member thinks has worked and not worked. Regardless of the specific data-gathering technique, gathering the project members subjective impressions about what worked and what did not is imporntatn and gathering that information soon after the project is complete is a good idea.
To realize maximum benefit from the software project history, package the conclusions drawn from the project history analysis in at least these two forms:
Create a planning checklist for future projets. If the project team already has a planning checklist, the checklist should be updated to address the major issues discussed in the project history.
Feed the major risks identified during the project into a top 10 risks list template, wich the next project can uses as the basis for its initial risk list.
With this I have cover all of the book Software project survival guide. I hope you have had a nice read as I did and expect to read more from me in the future. Until then, see you space cowboys.
Bibliography
McConnell, S. (1998). Software Project Survival Guide. Microsoft Press.
The end of a stage provides an opportunity to make course corrections and learn from the experience of the stage. Increasingly accurate estimates can be made as the project progresses, laying the groundwork for planning that will be done at the beginning of the next stage. Project experience to date should be recorded in a software project log so that it can be used by future projects.
Staged delivery is a flexible delivery approach, and a staged delivery plan can be executed with either of two general bents:
The stages can be deterministic, which means that they mainly provide a means of delivering the most important software functionality earlier than would be possible with an all-at-once approach.
The content of the stages can be redefined at the end of each stage, which means that the stages deliver the most important functionality early but also provide an opportunity to change course at the end of each stage.
A projects new hope.
Hold an omnibus change board meeting
The time just after a release is a natural time to consider proposed feature changes en masse. The whole project team topically works hard to achieve its software release, and spending a day or two considering a proposed changes can provide a welcome change of pace. Project members shouldn’t be subjected to a continuous barrage of feature change request. If the number of times changes are considered is not limited, project members can find themselves evaluating change impacts every few days or so, and those bits of work add up to a huge distraction.
Recalibrate estimates
The end of a stage is a good time to review the project’s actual schedule performance against its planned schedule performance and revise the project estimates in the first place by considering these questions.
Is the project scope still about the same as it was estimated by originally? if not, the estimate should be adjusted for the improved understanding of the project scope.
Has the feature set been changed?
Has the required level of performance, robustness or fit and finish changed?
Has the development team been as productive as expected?
Were necessary tasks omitted for the estimates? The estimates should be revised to account for these factors, too.
It isn’t wrong to underestimate the project size or overestimate the project team’s productivity early in the project; it’s wrong not to find and correct those estimation mistakes later in the project.
Projects time, price, and effort are different if we started making a cheese cake and close after they changed their minds to make a weeding cake.
Evaluate performance against the project plan.
Keep sure that the team is following the plan, and keep track of their advance to the current goal to make sure everybody keeps with the plan. This books approach makes it easy to follow the plan. Since the information is public, the plans are credible, humane and up to date.
Stick to the plan, if the plan is impossible to follow, replan. A sure way to lose control of the project is to abandon the original plan without putting a new plan in its place.
Archive project media
The archive is for the young and inexperience to look with fascination and the old and savvy the have at hand.
At the end of each stage, the environment used to create the software should be archived. Organizations often need to be able to recreate an old version of their software, which can be an impossible task of old versions of project components are unavailable.
The project should archive at least the following:
Copies of the release package, including CDs, printed documentation, collateral material, and packaging.
Source code.
Database or data files released with the software.
Data files used to create the software.
Custom tools developed for use on the project.
Commercial libraries.
Graphic resources, video resources, sound resources, and other resources contained in the software.
Source text files for help files and other documentation.
Build scripts.
Test scripts.
Test data.
Closure.
At the very end of the stage delivery we must also update the projects log, which is a valuable material for future projects.
Bibliography
McConnell, S. (1998). Software Project Survival Guide. Microsoft Press.
Finally we approach the release state for the software, after all of the hard work the team did we deserve to release quality product. Since we are using the staged delivering approach we need to make sure that every stage of the project is in a releasable state, this is a hard work for the programmers, since much of the work must be making the project in to a useful release state the main activity relies on polishing the code and eliminating most of the bugs.
“We avoid releasing a software product in this state”. – Project team developer maybe.
When to release
The answer must teeter on the line between releasing poor quality software early and releasing high quality software late. Severe methods can help you base the answers to this questions on a firmer footing than the instinctive guesses.
Defect counts.
By comparing the number of defect code this week with the past week you can know how close is the project to completion. If the number of defects this week exceeds the number of defects resolved this week then the software still has miles to go.
Statistics on effort per defect.
The data on time required to fix defects categorized by type of defect will provide a basis for estimating remaining defect correction work for this and future projects.
Defect density prediction.
One of the easiest to judge whether a program is ready to release is to measure its defect density. The number of defects per line of code. The more historical project data you have the more confidence you can be in the prerelease defect density targets.
Bibliography
McConnell, S. (1998). Software Project Survival Guide. Microsoft Press.
System testing is conducted in parallel with construction or a half step behind. It exercises the system from end to end, exposing defects that are the corrected by developers. Testers support developers by ensuring that the system’s quality remains high enough to support the integration of new code.
Philosophy
Test often becomes the critical-path activity on a software project because no une plans for it until the software is mostly complete. Without adequate preparation, ramping up testing activities quickly enough to fully test the software is impossible.
Although in this book’s approach system testing is developed right along with the software, the quality assurance role it plays is less dramatic that it is on a project that defer quality assurance until the end of the project.
System testing should test the entire scope of a system. Test cases should be designed to assure that each requirement is implemented and each line of code is executing without errors.
Strategic quality assurance
System testing can be sued not just to fix specific defects but take strategic action to improve the quality of the software. Commonly, about 80 percent of a system’s errors will be found in about 20 percent of its routines. Several software engineering studies have found that these routines contribute a disproportionate share of the total cost to a system.
Bibliography
McConnell, S. (1998). Software Project Survival Guide. Microsoft Press.
A project is not accomplished by only one person and in this chapter we focus in the many individuals that are directly related to the development of code, that is the working project team. The idea of the pragmatic programmer behind the pragmatic project is about to make the team a pragmatic team, by expanding the universe of action of pragmatism we now have a functional unit of people willing to cooperate for the sake of good programming.
As your project gets under way, we need to move away from issues of individual philosophy and coding to talk about larger, project-sized issues. We aren’t going to go into specifics of project management, but we will talk about a handful of critical areas that can make or break any project.
As soon as you have more than one person working on a project, you need to establish some ground rules and delegate parts of the project accordingly. In Pragmatic Teams, we’ll show how to do this while honoring the pragmatic philosophy.
When working on a team you must look up at the team while looking for broken windows, make your code clean and good to avoid this, and keep the communication about what is happening with the project in a pragmatic team people are looking for a meeting to keep in touch communication with the team is very important and helps to take more important decisions.
Testing
Testing is by no means an easy task, there is quality to be maintained and many things to keep in consideration when doing this, the testing is the part of the project where we look forward to the quality guide lines and go outside to look up defects in the code.
We need testing because programmers are unable to create bug free software.
There are several major types of software testing that you need to perform:
Unit testing
Integration testing
Validation and verification
Resource exhaustion, errors and recovery
Performance testing
Usability testing
Apollo program software minutes before deployment
Comment your code.
Pragmatic Programmers embrace documentation as an integral part of the overall development process. Writing documentation can be made easier by not duplicating effort or wasting time, and by keeping documentation close at hand—in the code itself, if possible.
There are basically two kinds of documentation produced for a project: internal and external. Internal documentation includes source code comments, design and test documents, and so on. External documentation is anything shipped or published to the outside world, such as user manuals. But regardless of the intended audience, or the role of the writer (developer or technical writer), all documentation is a mirror of the code. If there’s a discrepancy, the code is what matters—for better or worse.
Commenting source code gives you the perfect opportunity to document those elusive bits of a project that can’t be documented anywhere else: engineering trade-offs, why decisions were made, what other alternatives were discarded, and so on.
Great expectations.
Going back to the expectations of the client and the characteristics of the project, the users want something that can solve all of their needs and we as developers want to deliver but sometimes we deliver more than is required be weary of that.
In reality, the success of a project is measured by how well it meets the expectations of its users. A project that falls below their expectations is deemed a failure, no matter how good the deliverable is in absolute terms. However, like the parent of the child expecting the cheap doll, go too far and you’ll be a failure, too.
Give what the client desires.
Bibliography
Hunt, Andrew, and David Thomas. “The Pragmatic Programmer.” Addison Wesley 15 (2000).
During construction, the successful project teambecomes increasinglyvigilantabout findingways to make the software simpler and to control changes to it. Progress will be highly visible as the project manager monitors key progress indicators, including miniature milestones, defects, the top 10 risks list, and the system itself.
Coding standards
The goal of a Coding Standard is to make the whole program look more like a blanket made of a single material than a patchwork quilt made of mismatched scraps. The Coding Standard typically addresses several areas :
Layout of classes, modules, routines, and code within routines
Commenting of classes, modules, routines, and code within
routines
Variable names
Function names, including names for common operations such
as getting and setting values within a class or module
Maximum length of a routine in lines of source code
Maximum number of routines within a class
Degree of complexity allowed, including restrictions on the use
of the Goto statement, logical tests, loop nesting, and so on
Code-level enforcements of architectural standards for memory
management, error processing, string storage, and so on
Versions of tools and libraries to be used
Proyect objectives
As they did during detailed design, developers should continue looking for ways to optimize the project goals during construction. Construction presents many opportunities to make the project simpler or more complex, more robust or more fragile, more nimble or more ponderous.
Software integration procedure
This consists of the many processes that need to be done before we are sure that a process in the program is complete
Bibliography
McConnell, S. (1998). Software Project Survival Guide. Microsoft Press.
This is the part of the proyect where we find again that the proyect basics must be stablished before the proyect even begins, determine the requiremets, AKA listening the user is not enought, is one of the basics the proyects need in the planning stage, and requiremets is one of the biggest parts of the proyect because as the experience of the many proyect managers that have been to our class have pointed out, requirements are at the mercy of the imagination of the client.
What a fantastic show
Requirements
Many books seem to imply that the requirements are already there the moment you aproach the user to request them, the reality of the requirements and what is important to understand is that they are hidden beneath the ground.
Requirement : A statement of something that needs to be accomplished. Good requirements might include the follow.
An employee record may be viewed only by a nominatd group of people.
The cylinder-head temperature must not exceed the cirtical value, which varies by engine.
The editor will highlight keywords, which will be selected depending on the type of file being edited.
The first statement in the list above may have been stated by the users as “Only an employee’s supervisors and the personnel department may view that employee’s records.” Is this statement truly a requirement? Perhaps today, but it embeds business policy in an absolute statement. Policies change regularly, so we probably don’t want to hardwire them into our requirements. Our recommendation is to document these policies separately from the requirement, and hyperlink the two.
Abstractions Live Longer than Details
One very important thing to take into account when we make the system is that the user interface is as important as the system itself, we cannot create a system that is not addecuate for the user, every complex interfaces or non intuitive interfaces have the same problem, is that the functionality is of the system is not exploited by the user because he does not recognize with ease what is in front of him. Make easy to understand interfaces, make contact with the user and see what its currently using to know what he can use later.
In the current years it is imposible for Y2K problem to exist, vast amounts of memory are available and history has shown the damage such problems may cause.
How hard is your puzzle.
The popular buzz-phrase “thinking outside the box” encourages us to recognize constraints that might not be applicable and to ignore them. But this phrase isn’t entirely accurate. If the “box” is the boundary of constraints and conditions, then the trick is to find the box, which may be considerably larger than you think.
The key to solving puzzles is both to recognize the constraints placed on you and to recognize the degrees of freedom you do have, for in those you’ll find your solution. This is why some puzzles are so effective; you may dismiss potential solutions too readily.
can you connect all of the dots in the following puzzle and return to the starting point with just three straight lines—without lifting your pen from the paper or retracing your steps ?
BIBLIOGRAPHY
Hunt, Andrew, and David Thomas. “The Pragmatic Programmer.” Addison Wesley 15
Chapter 13. The detailed design activity during each stage extends the design work begun during architecture addressing many of the same issues but in more detail. The amount of detailed design work required depends on the project’s size and the developers expertise.
Architecture revisited.
During the detailed design, the development team will work in several design areas that were first explored during the architecture phase.
Program organization: at detailed design time, they are concerned with the programs organization at the class and runtime level.
Reuse analysis: Developers again investigate the possibility of reusing existing components and commercially available components in their design, but this time that investigation will explore reuse at a more detailed level.
Requirements resolution: Any requirements affecting a particular staged release must be resolved during detailed design phase of that release.
How much detailed design does a project need?
The omount of design work and the formality of that work depend on two factors: the expertise of the project’s developers and the difficulty of the project.
When the project has expert developers and is a simple project, the detailed desing work can be informal. Design work can proceed
Senior developer Stephanie ready to show the new interns at IBM north campus how to properly apply a lambda function
Successful projects look for ways to trade small increases in overhead for large decreases in project risk, and adding formality to design process is a classic what to do that.
Bibliography
McConnell, S. (1998). Software Project Survival Guide. Microsoft Press.
Chapter 6. Common knowledge with programming is once the codding part beggins is all about the keyboard the machine and the programmer, in reality programming is another kind of communication, and communications requieres understanding, being careful with what you do, and knowing what you do, what it does and why it does that, otherway we may end up coding by concidence.
That sweet sweet corsair K70 will have to wait until after proper colaboration with the testing team is stablished.
The programmers need to know the algorithm speed of the methods they created, most nontrivial algorithms handle some kind of variable input. Normally the size of this input will affect the algorithm: the larger the input, the longer the running time or the more memory used.
More significant algorithms are not linear. The good news is that many are sublinear. A binary search, for example, doesn’t need to look at every candidate when finding a match. The bad news is that other algorithms are considerably worse than linear; runtimes or memory requirements increase fer faster than n. An algorithm that takes a minute to precess ten items may take a lifetime to process 100.
Robbie Rotten finds out the intern name selection bubble sort.
Moving forth and afar from the diferent kinds of algoriths that may take another post or two to talk about. The next thing we need to take into account when coding is the refactoring. Refactoring the action of reviewing the code and modifing the code in order to make it more organic and natural the the solution in question. Clearly refactoring is an activity that needs to be undertaken slowly, deliberately and carefully.
Testing against contract
We like to think of unit testing as testing against contract. We want to write test cases that ensure that a given unit honors its contract. This will tell us two things: whether the code meet the contract, and whether the contract means what we think it means. We want to test that the module delivers the functionality it promises, over a wide range of test cases and boundary conditions.
What does this mean in practice? Let’s look at the square root routine.
Pass in a negative argument and ensure that is rejected.
Pass in an argument of zero to ensure that it is accepted.
Pass in values between zero and the maximum expressible argument and verify that the defference between the square of the result and the original argument is less than some small fraction of the argument.
This style of testing requires you to test subcomponents of a module first. Once the subcomponents have been verified, then the module itself can be tested.
Bibliography
Hunt, Andrew, and David Thomas. “The Pragmatic Programmer.” Addison Wesley 15
Stage planning is where we map out the detailed course of action for a stage to be permermed at the start of each stage delivery cycle. The project team creates an individual stage plan that describes how to conduct detailed design, coding, technical reviews, tests, integration and other activities during the stage. The most labor intensive planning activity is the creation of a list of miniature milestones, which helps the team track progress throughout the stage.
Each stage in a project using the staged delivery approach is essentially a miniature project.
Squidward with the rest of the sponge bob squarepants staff ready to begin stage planning. Colorized circa 1999.
Stage planning is a taxiing task, we want to make milestones for the next activities.
Requirements updates. in the early stages requirements to be implemented during the stages should be exactly what the project team specified during prototyping and requirements development. Later time should be allocated at the beginning of each stage to evaluate possible changes to requirements.
Detailed design. This is to be done near the beginning of each stage, developers flesh out the detailed design.
Construction.
Test case creation. This is to be created at the same time that the developers are working on a stages construction.
User documentation updates. The user manual/requirements specification is updated to describe the as-build software.
Technical reviews. This begin in earnest during the post-architecture period.
Defect corrections. Developers correct the defects uncovered by testing and reviews.
Technical reviews.
Technical coordination. Meetings between developers, testers and architecture designers.
Risk management. The project manager should review the project current top 10 risks list and determinate whether the current project plan adequately addresses the current risk.
Project tracking.
Integration.
Tired yet? Have a picture of a cute doggo.
In addition to their project tracking benefit, miniature milestones help the team to focus on the most important tasks. When only long-term milestones are used. the developers can easily lose a day here or a week there people spend time on detours that seem interesting or productive in some vague sense but fail to move the project forward.
How does a project get to be a year late?… One day at a time.
Frederick P. Brooks.
To close this chapter I would like to add that all of this planning is a warning for the future of the release of the project to always documents the milestones and document the ones that have been reached. If we do as follow future can’t stop us.
Squidward dealing with the humans inner fears.
Bibliography
McConnell, S. (1998). Software Project Survival Guide. Microsoft Press.
Robbie Rotten finds out the intern name selection bubble sort.
Enro Blog 