Proyect history

--Originally published at Enro Blog

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

--Originally published at Enro Blog

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.

Software release

--Originally published at Enro Blog

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

--Originally published at Enro Blog

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.


--Originally published at Enro Blog

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

Detailed design

--Originally published at Enro Blog


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

--Originally published at Enro Blog

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

Continue reading "Stage planning"


--Originally published at Enro Blog

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.


--Originally published at Enro Blog

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,

Continue reading "Quality"