Wednesday, September 23, 2009
Wednesday, August 26, 2009
Sunday, August 23, 2009
What is Risk??
1. Risk is a probability that some adverse circumstance will occur
a. Project risks affect schedule or resources.
b. Product risks affect the quantity of performance of the software being developed.
c. Business risks affect the organization developing or procuring the software.
2. SOFTWARE RISKS:
a. Staff turnover
- it affects the project.
- Experienced staff will leave the project before it is finished.
b. Management change
- it affects the project.
- There will be a change of organizational management with
different priorities.
c. Hardware unavailability
- it affects the project.
- Hardware that is essential for the project will not be
delivered on schedule.
d. Requirements change
- it affects the project and the product
- There will be a larger number of changes to the requirements
than anticipated.
e. Specification delays
- it affects the project and the product.
- Specifications of essential interfaces are not available on schedule.
3. Risk Management Strategies
Risk: Organizational financial problems
Strategy: Prepare a briefing document for senior manage-
Risk: Organizational financial problems
Strategy: Prepare a briefing document for senior manage-
problems ment showing how the project is making a very
important contribution to the goals of the
business.
Risk: Recruitment problems
Strategy: Alert customer of potential difficulties and the
Risk: Recruitment problems
Strategy: Alert customer of potential difficulties and the
possibility of delays, investigate buying-in
components.
Risk: Staff illness
Strategy: Reorganize team so that there is more overlap
Strategy: Reorganize team so that there is more overlap
of work and people therefore understand
each other jobs.
Risk: Defective components
Strategy: Replace potentially defective components with bought-in components of known reliability
Risk: Requirement changes
Strategy: Derive traceability information to asses requirements change impeact, maximze information hiding in the design.
Risk: Organizational restructuring
Strategy: Prepare a briefing document for senior management showing how the project is making a very important contribution to the goals of the business.
Risk: Database performance
Strategy: Investigate the possibility of buying a higher-performance database.
Risk: Underestimated development time
Strategy: Investigat buying components, investigate use of a program generator.
4. Before making a decision, we must first consider the consequences of it. If I were on this situation, I will accept the demand from my manager, and would not involve my project team to work with me because I know, they all have young children, and I must consider first their families' sake that myself. I am asked by a manager, therefore, i should have to obey him. Although I will work unpaid overtime, it's quite alright, because software analyst should do his duties and responsibilities on time without a doubt, and without making anyone involve especially that person have some priorities to be considered above all.
Risk: Defective components
Strategy: Replace potentially defective components with bought-in components of known reliability
Risk: Requirement changes
Strategy: Derive traceability information to asses requirements change impeact, maximze information hiding in the design.
Risk: Organizational restructuring
Strategy: Prepare a briefing document for senior management showing how the project is making a very important contribution to the goals of the business.
Risk: Database performance
Strategy: Investigate the possibility of buying a higher-performance database.
Risk: Underestimated development time
Strategy: Investigat buying components, investigate use of a program generator.
4. Before making a decision, we must first consider the consequences of it. If I were on this situation, I will accept the demand from my manager, and would not involve my project team to work with me because I know, they all have young children, and I must consider first their families' sake that myself. I am asked by a manager, therefore, i should have to obey him. Although I will work unpaid overtime, it's quite alright, because software analyst should do his duties and responsibilities on time without a doubt, and without making anyone involve especially that person have some priorities to be considered above all.
5. As for me, in accepting this job, I think it is much better if I will be a project manager in the software project and at the same time, a programmer. Because programmers were not only be the one who plan the development of the software project, but also the project managers. Furthermore, it's also regretting for myself that I would not apply what I have learned from the training on Java Programming, therefore, I f i should accept this job, I prefer to have two tasks concurrently, a project manager and a programmer as well.
Wednesday, August 12, 2009
Monday, August 10, 2009
What is CASE Tools???
CASE is the use of computer-based support in the software development process.
This definition includes all kinds of computer-based support for any of the managerial, administrative, or technical aspects of any part of a software project.
What Is a CASE Tool? Since the early days of writing software, there has been an awareness of the need for automated tools to help the software developer. Initially the concentration was on program support tools such as translators, compilers, assemblers, macro processors, and linkers and loaders. However, as computers became more powerful and the software that ran on them grew larger and more complex, the range of support tools began to expand. In particular, the use of interactive time-sharing systems for software development encouraged the development of program editors, debuggers, code analyzers, and program-pretty printers.
As computers became more reliable and in greater use, the need for a broader notion of software development became apparent. Software development came to be viewed as:
A large-scale activity involving significant effort to establish requirements, design an appropriate solution, implement that solution, test the solution's correctness, and document the functionality of the final system.
A long-term process producing software that requires enhancement through out its lifetime. The implications of this are that the structure of the software must enable new functionality to be added easily, and detailed records of the requirements, design, implementation, and testing of the system must be kept to aid maintainers of the software. In addition, multiple versions of all artifacts produced during a project must be maintained to facilitate group development of software systems.
A group activity involving interaction among a number of people during each stage of its life. Groups of people must be able to cooperate, in a controlled manner, and have consistent views of the state of the project.
This view of "programming in the large" resulted in a wide range of support tools being developed. Initially, the tools were not very sophisticated in their support. However, two important advances had the effect of greatly improving the sophistication of these tools:
Research in the area of software development processes gave rise to a number of software design methods (e.g., Jackson Structured Programming, the Yourdon Method) that could be used as the basis for software development. These methods were ideally suited to automated tool support in that they required step-by-step adherence to methods, had graphical notations associated with them, and produced a large number of artifacts (e.g., diagrams, annotations, and documentation) that needed to be recorded and maintained.
.....personal workstations and personal computers. These machines have relatively large memory storage capacities, fast processors, and sophisticated bit-mapped graphics displays that are capable of displaying charts, graphical models, and diagrams.
We refer to all of the above tools as CASE tools and posit the following definition:
A CASE tool is a computer-based product aimed at supporting one or more software engineering activities within a software development process.
Other authors have attempted to make finer-grained distinctions between differ ent classes of CASE tools along a number of dimensions. The most common distinctions are:
Between those tools that are interactive in nature (such as a design method support tool) and those that are not (such as a compiler). The former class are sometimes called CASE tools, while the latter class are called development tools.
Between those tools that support activities early in the life cycle of a soft ware project (such as requirements and design support tools) and those that are used later in the life cycle (such as compilers and test support tools). The former class are sometimes called front-end CASE tools, and the latter are called back-end CASE tools.
Between those tools that are specific to a particular life-cycle step or domain (such as a requirements tool or a coding tool) and those that are common across a number of life-cycle steps or domains (such as a documentation tool or a configuration management tool). The former class are sometimes called vertical CASE tools, while the latter class are called horizontal CASE tools.
Reference: http://www.sei.cmu.edu/legacy/case/case_whatis.html
This definition includes all kinds of computer-based support for any of the managerial, administrative, or technical aspects of any part of a software project.
What Is a CASE Tool? Since the early days of writing software, there has been an awareness of the need for automated tools to help the software developer. Initially the concentration was on program support tools such as translators, compilers, assemblers, macro processors, and linkers and loaders. However, as computers became more powerful and the software that ran on them grew larger and more complex, the range of support tools began to expand. In particular, the use of interactive time-sharing systems for software development encouraged the development of program editors, debuggers, code analyzers, and program-pretty printers.
As computers became more reliable and in greater use, the need for a broader notion of software development became apparent. Software development came to be viewed as:
A large-scale activity involving significant effort to establish requirements, design an appropriate solution, implement that solution, test the solution's correctness, and document the functionality of the final system.
A long-term process producing software that requires enhancement through out its lifetime. The implications of this are that the structure of the software must enable new functionality to be added easily, and detailed records of the requirements, design, implementation, and testing of the system must be kept to aid maintainers of the software. In addition, multiple versions of all artifacts produced during a project must be maintained to facilitate group development of software systems.
A group activity involving interaction among a number of people during each stage of its life. Groups of people must be able to cooperate, in a controlled manner, and have consistent views of the state of the project.
This view of "programming in the large" resulted in a wide range of support tools being developed. Initially, the tools were not very sophisticated in their support. However, two important advances had the effect of greatly improving the sophistication of these tools:
Research in the area of software development processes gave rise to a number of software design methods (e.g., Jackson Structured Programming, the Yourdon Method) that could be used as the basis for software development. These methods were ideally suited to automated tool support in that they required step-by-step adherence to methods, had graphical notations associated with them, and produced a large number of artifacts (e.g., diagrams, annotations, and documentation) that needed to be recorded and maintained.
.....personal workstations and personal computers. These machines have relatively large memory storage capacities, fast processors, and sophisticated bit-mapped graphics displays that are capable of displaying charts, graphical models, and diagrams.
We refer to all of the above tools as CASE tools and posit the following definition:
A CASE tool is a computer-based product aimed at supporting one or more software engineering activities within a software development process.
Other authors have attempted to make finer-grained distinctions between differ ent classes of CASE tools along a number of dimensions. The most common distinctions are:
Between those tools that are interactive in nature (such as a design method support tool) and those that are not (such as a compiler). The former class are sometimes called CASE tools, while the latter class are called development tools.
Between those tools that support activities early in the life cycle of a soft ware project (such as requirements and design support tools) and those that are used later in the life cycle (such as compilers and test support tools). The former class are sometimes called front-end CASE tools, and the latter are called back-end CASE tools.
Between those tools that are specific to a particular life-cycle step or domain (such as a requirements tool or a coding tool) and those that are common across a number of life-cycle steps or domains (such as a documentation tool or a configuration management tool). The former class are sometimes called vertical CASE tools, while the latter class are called horizontal CASE tools.
Reference: http://www.sei.cmu.edu/legacy/case/case_whatis.html
Subscribe to:
Posts (Atom)
