Proyect history

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.



McConnell, S. (1998). Software Project Survival Guide. Microsoft Press.

End of stage wrap up

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.



At the very end of the stage delivery we must also update the projects log, which is a valuable material for future projects.


McConnell, S. (1998). Software Project Survival Guide. Microsoft Press.

Software release

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.


McConnell, S. (1998). Software Project Survival Guide. Microsoft Press.

System testing

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.


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.


McConnell, S. (1998). Software Project Survival Guide. Microsoft Press.


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


McConnell, S. (1998). Software Project Survival Guide. Microsoft Press.

Detailed design


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.



McConnell, S. (1998). Software Project Survival Guide. Microsoft Press.

Stage planning

Chapter 12

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.yvvy86j

Squidward dealing with the humans inner fears. 


McConnell, S. (1998). Software Project Survival Guide. Microsoft Press.


Chapter 10 of software project survival guide. Is about the architecture of the software. During the architecture phase the architecture team interaction among system into major subsystems, specifies all the interactions among subsystems, and documents the software top level technical plans.

Easing into architecture

Architectural work should start when requirements development is about 80 percent complete. Resolving 100 percent of the requirements before beginning architectural work usually isn’t possible without delaying the project. By the time 80 percent of the requirements are known, the project is on firm enough footing to support creation of software architecture.

Characteristics of a good architecture

  • System overview. Needs to describe the system in broad terms.
  • Conceptual integrity. When you look at the architecture, you should be pleased at how natural and easy the solution is. It shouldn’t look like the problem and the architecture are stuck together with duct  tape.
  • Subsystem and organization. Once you realize that the goal of architecture is to reduce complexity, it becomes clear that the architect must focus as much on what to leave out of the software as on what to put in.
  • Strive for minimalism, simplicity, and coverage of all of the requirements, and don’t worry too much about finding the best solution.


McConnell, S. (1998). Software Project Survival Guide. Microsoft Press.


We now move on the chapter 9 of the Software Project Survival Guide where we take a peek at what is inside the project to make it from average/bad to outstanding/good. This chapter made me think about the many times I have acknowledge the power of the technology that I use from day to day, some of my favorite brands are dropbox and drive, incredible easy and intuitive tools that allow me to move without fear of losing the information I carry with me, ever since I use them I know that I can change my computer without fear of losing anything and I believe that is a great quality of the product, the fact that without saying it just makes my life easier and easier. The cost of the software goes even after the software is released. Software quality has a bottom-line impact on the cost of doing business. Low quality software increases the burden on end-user support. Leading companies like Microsoft.

Survival requires a commitment to quality assurance which involves the following elements.

  • Software quality assurance activities must be planned.
  • The plan for the software quality assurance activities must begin during software requirements activities or earlier.
  • A separate group for performing software quality assurance must exist. Depending on the size of the project that group might consist of one person.
  • Members of the group must be trained on how to perform software quality assurance activities.
  • Adequate funding must be provided for performing software quality assurance activities.

An effective quality assurance plan will call for several quality assurance activities: defect tracking, unit testing, source-code  tracing, technical reviews, integration testing, and system testing.

Defect tracking runs throught these quality assurance activities. The project team keeps records of each defect found, its source, when it was detected, when it was resolved, how it was resolved.

Unit testing is informal testing of source code by the developer who wrote it. The word “unit” can refer to a subroutine, a model, a class, or an event larger programming entity. Unit testing is usually performed informally but should be required for each unit before that unit is integrated with the master source or turned over for independent review or testing.

The “V” Concept of Software Testing


Life cycle testing involves continuos testing of the system dureng the developmental process.

At predetermined points, the result of the development process are inspected to determine the correcness of the implementation.

Source-code tracing is stepping through source code line by line in an interactive debugger. This work is performed by the developer who wrote the code. Many developers have found this to be an invaluable means of detecting coding defects, and my own experience bears this out.




McConnell, S. (1998). Software Project Survival Guide. Microsoft Press.

A man with a (development) plan

Requirements development

Users can have lots of ideas about what they want their projects to be and where they want their projects to be lead to. The mind of a user is fertile resource of requirements, but the project team must focus the attention of the user to its most needed function.

the most difficult is not the act of recording what the user want, it is the exploratory, developmental activity of helping users figure out what they want.

The following steps are recommended by the book as those that we the project team should follow in order to accomplish proper requirements.

  • Identify a set of key end users.
  • Interview the end users
  • Build a simple user interface prototype
    • User paper storyboards if possible
  • Develop a style guide
  • Fully extend the prototype
  • tread the fully extended prototype as the baseline specification
  • Write the detailed end-user documentation based on the prototype
    Create a non-user interface requirements doc

Identify a set of key end users

Localizing the correct user for the project is a very important part of the project plan, to identify this kind of user you must look for that that will be in contact with the software the most and will give you correct feedback about the kind of software they expect.

Interview the end users

Not much to say, its again, you must hear the end user and its needs, the project must be focused to fulfil what the end user wants. But the user is not very good at making correct architecture about its project and so we must look further than the user. but the user knows what he wants it to look like and so you can take proper information regarding what kind of interface to craft.

Build a simple user interface prototype


End users reaction first reaction after looking at the prototype.

Prototyping is all about how the result software will look. The point of this activity is to present many alternatives to the user before commit much effort to any approach. The project team must consist of a small group of senior developers that know how to make fast interfaces that give a feeling of comfort with the less amount of effort.

and make sure the user understand that the prototype is “just a prototype” otherwise expectations may rise or go down the drain.

Paper storyboards

This technic on this approach, developers and users gather together to draw on paper what they expect the and product to look like, they draw windows, buttons, etc. This approach is useful because the user can put some effort in making the prototype, it also helps at illustrating that a prototype is a small look of what the software must look and also avoid the team to over extends with the prototype.

On the other hand, some users are not very good at knowing what the prototype must look and this defies every point of the prototyping.

Develop a style guide

The developers should set standards for the look and feel of the application. This document should be at most 6 pages long where we describe things like where is the dev team placing the buttons. This is to create standards that lead the development of the user interface.

Fully extended prototype

The project’s vision statement enables developers to align their work in a general way; the detail user interface prototype provides the detailed vision that enables them to align their work in thousands of smaller ways. Here is a partial list of the functionality

  • all dialog boxes.
  • all graphical input screens.
  • All graphical and textual outputs.
  • Interactions with the operating system, such as importing and exporting data to the clipboard.
  • Interaction with all third-party products.

Prototype as the baseline specification

The organization will base its estimates, plans, staffing, architecture, designs, and development work on it. It is both appropriate and necessary that the decision makes commit to the prototype and that changes to it be systematically controlled.

Write the detailed end-user documentation

The early development of the end-user documentation fleshes out the details of the software demonstrated by the user interface prototype, filling in gaps and flushing out inconsistencies.

Create a separate, non-user-interface requirements document

Specifications of detailed algorithms, interactions with other hardware and software, preformation requirements, memory and usage, and other less visible requirements can be recorded in a separate requirements document.+


McConnell, S. (1998). Software Project Survival Guide. Microsoft Press.