Colegio De Dagupan MASTER IN INFORMATION TECHNOLOGY Randy M.

Ventayen MIT-1

Chapter 7: Why did the Tower of Babel Fail? When I first heard about this essay, I know that God is the one who disallow the creation of tower babel, because it is not based on the will of God. But lets go on the other side of the story where communication is one reason why they fail. I dont really agree that this example written in the bible should be included in the software engineering essay, since we should not question our God. Communication patterns, meetings, documents etc. should be decided up-front and made available to everyone necessary. People who don't know how to manage, should NOT. People who make unsound technical decisions should NOT. Specialization of roles can occur with both types work efficiently at what they do best without worrying about what they can't do. A Management Audit of the Babel Project - By the book of Genesis, the tower of Babel was man's 2nd engineering undertaking after Noah's Ark. Babel was the 1st engineering fiasco. 1) It had a clear, impossible mission, but it failed long before this limitation. 2) Lots of manpower. 3) Lots of material. 4) No time constraints. 5) Adequate technology existed. What caused it to fail were 1) COMMUNICATION and 2) ORGANIZATION. Communication in the Large Programming Project - The 'Babel syndrome' exists today in that groups change their assumptions without informing others. 1) There should be clear

definition of intergroup dependencies, encouraging hundreds of calls to commonly interpret the written documents. 2) There should be regular project meetings with one team after another giving technical briefings. 3) A formal project workbook must be started at the beginning. Communication is key to successful Project Management specially in creating softwares. If project staff do not know what their tasks are, or how to accomplish them, then the entire project will grind to a halt. If you do not know what the project staff are (not) doing then you will be unable to monitor project progress. And if you are uncertain of what the customer expects of you, then the project will not even get off the ground. Maintaining open, regular and accurate channels of communication with all levels of project staff and stakeholders is vital to ensuring the smooth flow of instructions from customer to factory floor and sufficient warning of risks and changes to enable early assessment and preparation.

Chapter 15: The Other Face The correct level of documentation must exist for each guide and the information must flow smoothly from overview down through each level of detail. As stated in the chapter 15s overview of the Mythical man month essay, What we do not understand, we do not possess (Goethe). This state that documentation of a program is very vital for the understanding for all. Flow Charts are pretty useless, and Program should be self-documented to some standard. Flow charts are most thoroughly oversold, most programs don't need them, and few need more than one page of them. Goldstine and von Neumann introduced them to group inscrutable machine-language statements into clusters of significance, but as Iverson early recognized, systematic high-level languages already cluster related statements. It is obsolete! To believe a program, some description of how one knows it is working is supplemented. Every copy of a program shipped should include some small test cases. To modify a program, besides a well-commented listing, module structure graph, descriptions of algorithms, file layouts, pseudo code, discussion of planned extensibility (locations of hooks). The documentation created for manual software testing or automated software testing plays an important role in projects testing phase. It is not professional to rely on verbal communications. To be on safe side, it is advised to keep each step documented and the documents prepared handy. Documentation aids in a systematic approach to any testing process and on fixing issues that arise at a later stage. One main question arises is what should be documented and what can be omitted. As a rule each and every step, no matter how insignificant it might be, should be document. During

manual software testing documentation will include specifications, test designs, test plan, prevalent business rules, reports, configurations details, changes in code, test cases, bug reports, user manuals, etc. Proper documentation helps an organization save its time, effort and money. Once the details are documented, they should be placed at a reservoir where easy search and timely availability of the records is feasible. These documents come handy in times of any dispute or comparing the requirement specification with the delivered product.

Chapter 10: The Documentary Hypothesis This is for short, if there is no documents, then it is bound to fail. Documents should be regarded as tools, the right ones used for a project are invaluable in communicating a plan and achieving it. There are several reason Why have Formal Documents, Writing decisions down is essential. It highlights gaps & inconsistencies. Writing requires hundreds of mini-decisions which clarifies fuzzy policies.Documents will communicate decisions to others. A manager's fundamental task is communication (not decision making). They give a manager a database & checklist, reviewing them will highlight what changes of emphasis or shifts in direction are needed. The "total MIS" where an executive strokes an inquiry, & the display flashes the answer will never happen because only a fraction of an executive's time is spent getting information from outside his head. The rest is communication: hearing, teaching, reporting, exhorting, counseling, encouraging. The task of the manager is to develop a plan and realize it. Only a written one is precise & communicable. If their comprehensive & critical nature is recognized, the manager can approach them as friendly tools rather than annoying busy work.