Montao, Grace N.

BSIT 3-3N
Software Engineering

1. How do you want to see yourself 3yrs and 10yrs from now?

- Normally 3 years by now i really see myself as a college graduate and finding a job. Also hopefully I see
myself having my first ever job that is connected with my degree. Little by little I am fulfilling my goals in
life.

- I see myself in 10 years as an independent person. Striving hard to achieve and fulfill my life goals as a
professional. Starting to travel with my mom and giving her treats.

Where do you see yourself 3 years and 10 from now?

- 3 years from now, I am in a company where they were able to enhance my skills. Learning new things
and applying them.

- In 10 years, I see myself as a stable employee of a company where I am able to bring out my best and
apply all my experiences. Also hopefully, be able to produce my own business for future funds.

2. Strength and Weakness

- The strength that keeps me going is when the people that are precious to me are happy in what I am
doing. Those people who supports and believes in me. They are the one that keeps me going. Also the
challenges, it gives me more courage to fight.

- My weakness is simple, when people that are used to be there for me, leaves.

3. How do you want to be remembered?

- I am the person that they can count on anytime.

What is Software Engineering?

"the systematic application of scientific and technological knowledge, methods, and experience
to the design, implementation, testing, and documentation of software"The Bureau of Labor
StatisticsIEEE Systems and software engineering - Vocabulary
"The application of a systematic, disciplined, quantifiable approach to the development,
operation, and maintenance of software"IEEE Standard Glossary of Software Engineering
Terminology
"an engineering discipline that is concerned with all aspects of software production" Ian
Sommerville
"the establishment and use of sound engineering principles in order to economically obtain
software that is reliable and works efficiently on real machines"Fritz Bauer
Products of Software Engineering

Software
Documentation
Data

Software Myths

Pressman (1997) describes a number of common beliefs or myths that software managers,
customers, and developers believe falsely. He describes these myths as ``misleading attitudes that
have caused serious problems.'' We look at these myths to see why they are false, and why they
lead to trouble.

Software Management Myths. Pressman describes managers' beliefs in the following mythology as
grasping at straws:

Development problems can be solved by developing and documenting standards. Standards

have been developed by companies and standards organizations. They can be very useful.
However, they are frequently ignored by developers because they are irrelevant and
incomplete, and sometimes incomprehensible.
Development problems can be solved by using state-of-the art tools. Tools may help, but
there is no magic. Problem solving requires more than tools, it requires great understanding.
As Fred Brooks (1987) says, there is no silver bullet to slay the software development
werewolf.
When schedules slip, just add more people This solution seems intuitive: if there is too much
work for the current team, just enlarge it. Unfortunately, increasing team size increases
communication overhead. New workers must learn project details taking up the time of those
who are already immersed in the project. Also, a larger team has many more communication
links, which slows progress. Fred Brooks (1975) gives us one of the most famous software
engineering maxims, which is not a myth, ``adding people to a late project makes it later.''

Software Customer Myths. Customers often vastly underestimate the difficulty of developing
software. Sometimes marketing people encourage customers in their misbeliefs.

Change is easily accommodated, since software is malleable.

Software can certainly be changed, but often changes after release can require an enormous
amount of labor.
A general statement of need is sufficient to start coding
This myth reminds me of a cartoon that I used to post on my door. It showed the software
manager talking to a group of programmers, with the quote: ``You programmers just start
coding while I go down and find out what they want the program to do.'' This scenario is an
exaggeration. However, for developers to have a chance to satisfy the customers
requirements, they need detailed descriptions of these requirements. Developers cannot
read the minds of customers.

Developer Myths. Developers often want to be artists (or artisans), but the software development
craft is becoming an engineering discipline. However myths remain:

The job is done when the code is delivered.

Commercially successful software may be used for decades. Developers must continually
 maintain such software: they add features and repair bugs. Maintenance costs predominate
over all other costs; maintenance may be 70% of the development costs. This myth is true
only for shelfware --- software that is never used, and there are no customers for next
release of a shelfware product.
Project success depends solely on the quality of the delivered program.

Documentation and software configuration information is very important to the quality. After
functionality, maintainability, see the preceding myth, is of critical importance. Developers
must maintain the software and they need good design documents, test data, etc to do their
job.

You can't assess software quality until the program is running.

There are static ways to evaluate quality without running a program. Software reviews can
effectively determine the quality of requirements documents, design documents, test plans,
and code. Formal (mathematical) analyses are often used to verify safety critical software,
software security factors, and very-high reliability software.

Software Engineering tools, methods and processes

Software engineers use many tools and practices in making software. Some of the most common
are:

Flowcharts
UML diagram
Debugging tools
Compiler
Text editor, usually part of an IDE - Integrated Development Environment

A software development methodology or system development methodology in software engineering

is a framework that is used to structure, plan, and control the process of developing an information
system. There are the following methodologies:

Agile Software Development

Crystal Methods Dynamic
Systems Development Model (DSDM)
Extreme Programming (XP)
Feature Driven Development (FDD)
Joint Application Development (JAD)
Lean Development (LD)
Rapid Application Development (RAD)
Rational Unified Process (RUP)
Scrum Spiral Systems Development Life Cycle (SDLC)
Waterfall (a.k.a. Traditional)

In software engineering, a software development process is the process of dividing software

development work into distinct phases to improve design, product management, and project
management. It is also known as a software development life cycle. The methodology may
include the pre-definition of specific deliverables and artifacts that are created and completed by a
project team to develop or maintain an application.
Most modern development processes can be vaguely described as agile. Other methodologies
include waterfall, prototyping, iterative and incremental development, spiral development, rapid
application development, and extreme programming.
To whom it may concern,

Please excuse my daughter Grace Montao because she will be absent in 4 days ( November 29 -
December 2) for a church activity, the annual training for leaders where she will be participating as part
of the representatives.

Thank you for your consideration about this matter.

Sincerely,

Merlita Montao